Re: A DNS Based Mapping Peering System for Peering CDNs

["Abbie Barbir" <abbieb@nortelnetworks.com>]

ok,


> The main metrics are time and money.  Time might be related to hops or
> measured latency; money is the cost of sending the bits.  If QOS is
> available, then maybe we need to bring in those attributes.

that's alright, here we may also talk about QOS for peered CDNs, basically, the way
i see it , we may end with various flavors of
a direction system. This will bring the need to define minimum criteria's to be
adopted within each  CDN for it to be qualified to be peered. This will be true for
the mapping, distribution systems and probably for the accouting system.


>
> If the tables are exchanged, then there are graph algorithms to
> efficiently find a short distance between two points.  In the usual OSPF
> calculation, each party uses all the other parties tables to find good
> paths from its site to all the other destinations.
>

ok agreed.


>
> For the "find the closest surrogate" problem, a "director" must
> do this calculation using the client as the origin.  It's still the same
> calculation, but the storage requirements might be much greater
> (because of the multiple origin problem and because "destination"
> depends on what object you are trying to access).
>

I do agree with you. However, there are methods that could be used to make this
task relatively simple.
If there is enought interest we could discuss the methods in future communications.

regards
abbie
---------



>
> Hilarie
>
> >>> "Abbie Barbir" <abbieb@nortelnetworks.com> 11/30/00 08:44AM >>>
> Thanks for the reply, please find my notes below.
>
> Hilarie Orman wrote:
>
> > First, there's more than one metric that could be used, so the tables
> > must give distance in terms of named metrics.
>
> can we elaborate on those metrics. Can we elaborate on the distances and what do
> they represent?
>
> > Second, in order to do this, CDN's must exchange tables that
> > identify their surrogates and measured distances.  I thought
> > there was some sensitivity about this level of disclosure.  Thus,
> > the architecture would only require that some form of query/response
> > protocol be used; this might be a DNS query.
>
> ok agreed on the sensitivity. However, let us assume that all tables are shared,
> the distances that are measured
> still do not reflect the distance from the surrogate to the client. If it does
> can you explain how??
>
> > Third, shortest-path-first is a reasonable way to minimize a graph
> > metric parameter for those parties who are willing to exchange
> > tables.
>
> ok this can be done, but again are we minimizing the graph to get to a node that
> is not the client. If not can you elaborate?
>
> Regards
> Abbie
>
> >
> >
> > Hilarie
> >
> > >>> "Abbie Barbir" <abbieb@nortelnetworks.com> 11/29/00 02:50PM >>>
> > Martin May wrote:
> >
> > > We work on this issue. Indeed, we are about to propose the exchange of
> > > "mapping tables" (PMT)  during the peering process. A tree based DNS-MS
> > > system simplifies the peering exchange especially if footprints are
> > > used.
> > >
> >
> > good to hear that.
> >
> > on a different note, any ideas on methods that could choose a particular
> > surrogate that is closest to the client. It could be beneficial if this aspect
> > of mapping start getting more attention. Any feedback people????
> >
> > ----
> > abbie
begin:vcard 
n:Barbir, Ph.D.;Abbie
x-mozilla-html:FALSE
org:Nortel Networks;613 763 5229
adr:;;;;;;
version:2.1
email;internet:abbieb@nortelnetworks.com
title:Senior Designer
x-mozilla-cpt:;0
fn:Abbie Barbir, Ph.D.
end:vcard