RE: hard questions: request routing

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

Abbie Barbir writes:
 > 
 > see remarks inside,
 > 
 > > -----Original Message-----
 > > From: Oliver Spatscheck [mailto:spatsch@research.att.com]
 > > Sent: Monday, April 02, 2001 12:53 PM
 > > To: Barbir, Abbie [CAR:CC70:EXCH]
 > > Cc: cdn@ops.ietf.org
 > > Subject: RE: hard questions: request routing
 > > 
 > > 
 > > 
 > > I don't know why you think I am considering layer 3 at all. All I want
 > > to optimize is to find the surrogate which serves the content 
 > > the fastest.
 > > This surrogate is changing constantly since the surrogate loads and
 > > network delays are in constant flux. So determining a single 
 > > tree in terms
 > > of redirection at content distribution time does not work, since this
 > > tree is not sensitive to changes in load and delay.
 > > 
 > 
 > oliver, you are mixing issues here. The content tree is a tree of possible
 > content hops.

Thank you for defining it.

 > for example, CDN A, B and C are peered for content obj1. Hence, the possible
 > routes are
 > a->b
 > a->C
 > b->c
 > a->b->C
 > etc .. etc.
 > 
 > This tree can be formed off line. The number of levels in the tree is
 > determined by the
 > DPS system at the start. No load info is needed.

OK. So you are constraining the topology at some early stage. This takes
dynamic topology out of the scope of the RR protocol. This is definitely
one solution. I assume you restrict the routes (which might form 
a graph) to a tree using the DPS. Is that correct? 

 > 
 > > So what we need is a redirection tree (Is that what you mean with
 > > content tree?) and everybody has to have the same view of this
 > > tree at each point in time in the presence of updates to surrogate
 > > and network load information.
 > > 
 > > If you can tell me how to calculate this tree without an 
 > > atomic update or the
 > > risk of transient loops in the multiple local views of the 
 > > tree I would
 > > appreciate it. 
 > > 
 > > Oliver
 > 
 > Here is where the issues get mixed.
 > The redirection tree is basically a means to traverse the above tree based
 > on some metrics.
 > 
 > Hence, what my apoproach provide is an encoding mechanism that 
 > 1. create the content tree first (all hops are known after DPS agree on it)

Again you make the topology completely static, this is one solution
to the problem, however, it deals not very well with CDN failures.
You could argue that this is a rare case... .

 > 2. Allow the RRS to traverse the tree based on metrics (your redirection
 > tree).
 > 3. Spit out the result in an encoded fashion where all nodes in the tree are
 > represented
 >    in the answere.
 > 
 > 
 > Please stop coupling the redirection tree with the content tree. The content
 > tree 
 > represents possible paths for the content.
 > 
 > Please do not mix the redirection tree (metric based, layer 3) with the
 > content routing tree.
 > 

The redirection tree is not layer 3. The metric I am concerned about are
all layer 7 as is the redirection tree. Everything is overlay.

So you have three trees in your solution:

- content tree
- redirection tree
- content routing tree

You defined the first two but not the last. To help me not to confuse
them a definition would help.

Overall your solution moved the problem of loop detection and
avoidance from RRS to the DPS. You further argue that updates to
the DPS are rare and therefore, a global atomic update is feasible.

Does that summarize your solution correctly?

Sorry if I am slow in understanding your solution. However, it is hard
to understand a solution having different scenarios in mind.

Oliver