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