oliver,
I will remark tom. due to lack of time
abbie
> -----Original Message-----
> From: Oliver Spatscheck [mailto:spatsch@research.att.com]
> Sent: Monday, April 02, 2001 2:31 PM
> To: Barbir, Abbie [CAR:CC70:EXCH]
> Cc: Oliver Spatscheck; cdn@ops.ietf.org
> Subject: RE: hard questions: request routing
>
>
> 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
>
>