Re: A DNS Based Mapping Peering System for Peering CDNs

[Eric Dean <eric@crystalballinc.com>]

Is it really necessary to derive the metrics or is it important to just
accommodate for a metric of some sort and allow the operator to determine
what parameters they are sensitve towards?...which is how OSPF works.

On Thu, 30 Nov 2000, Hilarie Orman wrote:

> 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.
> 
> 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.
> 
> 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).
> 
> 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
> 
>