[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: hard questions: request routing

To: Oliver Spatscheck <spatsch@research.att.com>
Subject: RE: hard questions: request routing
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
Date: Mon, 2 Apr 2001 10:38:27 -0400
Cc: cdn@ops.ietf.org
Delivery-date: Mon, 02 Apr 2001 07:45:00 -0700
Envelope-to: cdn-data@psg.com

Title: RE: hard questions: request routing

hi,

just to clarify, peering on the fly is associated with newly participating CDNs.

abbie

> -----Original Message-----
> From: Oliver Spatscheck [mailto:spatsch@research.att.com]
> Sent: Friday, March 30, 2001 4:12 PM
> To: Barbir, Abbie [CAR:CC70:EXCH]
> Cc: cdn@ops.ietf.org
> Subject: RE: hard questions: request routing
>
>
>
>
> Abbie,
>
> I am a littel bit confused about what exactly your are
> proposing. Let me try an example for a DNS based RRS:
>
> - The domain is www.foobar.com
> - The authoritative RRS is CDN A
> - The content has been distributed to CDN A, B and C.
>
> 1. CDN A now decides to redirect a particular client DNS
> resolution for
> www.foobar.com to CDN B (because of better performance,
> price etc ...)
> using a CNAME lets say cname1.cdnb.com .
>
> 2. When CDN B receives the resolution request for
> cname1.cdnb.com it decides
> (again based on some metric like price, performance etc..)
> that CDN A
> would better serve the client. In this case CDN B
> redirects the client
> to CDN A using cname1.cdna.com .
>
> 3. Now CDN A decides again that CDN B is better for that particular
> client and redirects the request using CNAME to cname1.cdnb.com
>
> and now we have a RRS loop.
>
> Obviously it is easy to break the loop between two CDNs in the
> example. However, it is not as trivial to break transient
> loops and loops
> between more than two CDNs.
>
> How does your approach solve that problem?
>
> Oliver
>
>
> Abbie Barbir writes:
> > 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
> > >
> > >
> > >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > <HTML>
> > <HEAD>
> > <META HTTP-EQUIV="Content-Type" CONTENT="text/html;
> charset=iso-8859-1">
> > <META NAME="Generator" CONTENT="MS Exchange Server version
> 5.5.2654.19">
> > <TITLE>RE: hard questions: request routing</TITLE>
> > </HEAD>
> > <BODY>
> >
> > 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 [<A
> HREF=""mailto:spatsch@research.att.com">mailto:spatsch@research
> .att.com</A>]
> > > 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 [<A
> HREF=""mailto:dima@krioukov.net">mailto:dima@krioukov.net</A>]
> > >  > > 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
> > >  
> > > 
> > > 
> > 
> >
> > </BODY>
> > </HTML>
>

Prev by Date: RE: hard questions: request routing
Next by Date: RE: hard questions: request routing
Prev by thread: RE: hard questions: request routing
Next by thread: RE: hard questions: request routing
Index(es):
- Date
- Thread