RE: hard questions: request routing

[Eric Dean <eric@crystalballinc.com>]

There is the metric, which probably should be delay, and then there is the
loop prevention mechanism. I agree, a hop count is not of much value with
CDI when everyone should be an ultimate hop.
 
On Sat, 31 Mar 2001, Dmitri Krioukov wrote:

> I'd like to add that the path vector protocols are the worst known
> ones from the loop prevention and convergence standpoints (cf.
> "Delayed Internet Routing Convergence" by Craig Labovitz
> et al., for example).
> 
> On the hand, why can't something related to delay be a good
> candidate?
> 
> thanks,
> --
> dima.
> 
> > -----Original Message-----
> > From: owner-cdn@ops.ietf.org [mailto:owner-cdn@ops.ietf.org]On Behalf Of
> > Oliver Spatscheck
> > Sent: Friday, March 30, 2001 5:41 PM
> > To: Eric Dean
> > Cc: cdn@ops.ietf.org
> > Subject: RE: hard questions: request routing
> >
> >
> > Eric Dean writes:
> >  >
> >  > > 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.
> >  >
> >  > By topology changes, you mean with respect to the client
> >
> > Yes I mean the topology of the RRS with respect to the client.
> > For example:
> >
> > CDN A redirects to CDN B for client C
> >
> > topology change:
> >
> > CDN A redirects to CDN D for client C
> >
> >  >
> >  > > 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
> >  >
> >  > Another important differentiator is that IP networks are
> >  > destination-based, while CDN's are client source based.
> > Request routing
> >  > looks at the source of the requestor making content requests.  I don't
> >  > understand why simple path-vectors do not address loop prevention.
> >
> > Simple path vectors prevent loops in the steady state. I was complaining
> > about two issues:
> >
> > 1. Path vectors do not prevent transient loops which can happen during
> >    changes in the value of the chosen metric. This changes  have to
> >    be visible to all RRS before we can guarantee that there are
> >    no transient loops. Since the updates of the metric will be
> >    frequent the transient loops will be frequent.
> >
> > 2. Using a single metric. I was makeing the point that RRS path length is
> >    obviously the wrong metric and that I don't think we know THE
> >    single metric we can all use to achieve the 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
> >  >
> >  > I'm not sure how such restrictions can be imposed.
> >  >
> >
> > They would be enforce by the SLAs.
> >
> > Oliver
> 
> 

Eric Dean
President, Crystal Ball Inc.
W 703-322-8000
F 703-322-8010 
M 703-597-6921