hi all,
The looping problem can be solved in an efficient matter if the problem is attacked
in a structured way.
Here we have to keep in mind that there is a correlation between the distribution system,
accounting system and the Request routing phase.
Take for example the DNS based apprach.
- The distribution protocol will basically get you the content.
- The winning CDN (the one that get the new content is informed)becomes autoritative on the
content.
- All participating CDNs for that content must also be informed.
- The RRS in the winning CDN must be able to resolve future requests to that content (ASAP).
- The billing system must be able to track all the middle men (every CDN that directs
a request will want $$$$$)
For DNS based solutions, the winning CDN is made autorartive on the new content. This
means, may be up to two days delay for the DNS system to propgate the news in the DNS
system.
Basically, to route on content, this means an overlay system that will resolve the
looping problem. The end result, a structured approach is needed that addresses the problem.
This is very feasible if you think of content routing (RRS) as an overlay system.
Basically, solve the problem assuming that there is no access to any metrics
(no bgp, no latency , no hops, no etc.., assume that network delays are equal..), all what you have is just content.
abbie
> -----Original Message-----
> From: Oliver Spatscheck [mailto:spatsch@research.att.com]
> Sent: Friday, March 30, 2001 11:26 AM
> To: Cain, Brad
> Cc: 'Dmitri Krioukov'; cdn@ops.ietf.org
> Subject: RE: hard questions: request routing
>
>
> Cain, Brad writes:
> >
> >
> > > -----Original Message-----
> > > From: Dmitri Krioukov [mailto:dima@krioukov.net]
> > > Sent: Thursday, March 29, 2001 9:03 PM
> > > To: Cain, Brad
> > > Cc: cdn@ops.ietf.org
> > > Subject: RE: hard questions: request routing
> > >
> > >
> > > I still think that the easiest way to
> > > attack p.2 is a very straightforward hard
> > > choice -- everyone agrees on the single
> > > metric whose primary purpose is proper
> > > inter-CDN request routing with loop
> > > avoidance --
> >
> > it is the easiest but i highly doubt we will get
> > consensus... if we were to go that way, i'd
> > propose two metrics to be evaluated in this
> > order:
> > 1. simple path vector (ala bgp)
> > 2. 64 bit "generic" metric
> >
> > #2 would have to be generic because there is no way
> > to get people to agree on something that is measurable
> > (i.e. delay)
> >
> > as for #1, it is sensible for basic loop preventation (plus
> > operators are used to opaque policies and wouldn't go for
> > a new paradigm like link state)
> >
> >
>
>
> One concern with this approach would be transient routing
> loops. Simply
> providing a path vector in the RR protocol does not prevent
> transient routing
> loops. The severity of the problem depends on the dynamic of
> the topology
> changes. Providing similar information on a per request basis
> would prevent
> that problem, however, it is a rather ugly solution.
>
> Another concern here is that the goal for CDI is slightly
> different from L3
> peering (best effort connectivity). CDNs were invented to
> decrease latency,
> increase throughput and reduce cost. Therefore, forcing
> everybody to use a
> metric which does not consider those three issues might make
> CDI fairly
> useless. A primary metric of path length would be completely
> meaningless in
> terms of performance since the path length in terms of RRS
> has absolutely
> nothing to do with the distance between cache and client. On
> L3 there is
> at least some correlation here, but with CDI there is none. The
> RR hop count is based on business relation ship and the L3 hop count
> of the actual data flow after redirection is based on L3 topology.
>
> Believe me I would rather have a simple solution to this problem,
> however, not for the prize of giving up the major goals of CDI.
>
> At this point I think the most sensible solution might be to restrict
> the number of redirections to at most:
>
> content owner->authoritative CDN->second level CDN
>
> This will allow us to solve the remainder of the RR problem.
> We can then
> revisit the loop avoidance problem when we fully understand
> the other issues
> involved. I also think in the long run it will be extremely
> valuable to allow
> deeper relationships, but I am unsure if we understand all the other
> issues of RR well enough today to decide what the right solution is.
>
>
> Oliver
>
>
>