RE: hard questions: request routing

[Oliver Spatscheck <spatsch@research.att.com>]

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