RE: hard questions: request routing

["Mark Day" <markday@cisco.com>]

I need a volunteer, probably from the active participants in this thread, to
summarize the issues and the state of the conversation so far.  I have a
sense that we have wandered into a rathole but I'm willing to be convinced
otherwise.

If there's new and relevant material being defined or discussed, I need to
understand how we propose to capture it -- in particular, whether some of
this needs to go into the requirements drafts (what, and into which drafts?)
or whether this should be captured in some new draft (what is it, and who's
writing it?)

Thanks,

--Mark

Mark Stuart Day
Senior Scientist
Cisco Systems
+1 (781) 663-8310
markday@cisco.com

> -----Original Message-----
> From: owner-cdn@ops.ietf.org [mailto:owner-cdn@ops.ietf.org]On Behalf Of
> Oliver Spatscheck
> Sent: Tuesday, April 03, 2001 11:04 AM
> To: Abbie Barbir
> Cc: cdn@ops.ietf.org
> Subject: RE: hard questions: request routing
>
>
> Abbie Barbir writes:
>  >
>  >
>  > >
>  > >
>  > > Abbie,
>  > >
>  > > 	I think we are fighting over terminology at this point.
>  > > Let me try to make
>  > > an example:
>  > >
>  > >
>  > > If I understand you right the DSP is building a content tree.
>  > > The content tree is managed by the authoritative CDN which has
>  > > a global view of the content tree.
>  > >
>  > > For example:
>  > >
>  > > - CDN A is authoritative for a particular customer
>  > > - All CDN's B C D have business arrangements with each other
>  > >
>  > > So possible content trees are, for example:
>  > >
>  > > I.)
>  > >
>  > >   A
>  > >   |
>  > >   B
>  > >   |
>  > >   C
>  > >   |
>  > >   D
>  > >
>  > > or
>  > >
>  > > II.)
>  > >
>  > >    A
>  > >    |\
>  > >    C B
>  > >      |
>  > >      D
>  > >
>  > > or ....
>  > >
>  > > What I meant with "you are constraining the topology at some
>  > > early stage"
>  >
>  > the constrain is in the size of the tree, number of content hops,.
>  >
>  >
>  > > is that the authoritative DPS has to decide early on if the
>  > > content tree has topology I.) or II.). And it also has to
>  > > assure that the content tree is actually a tree and not a graph.
>  > > For example, the business relationship allows for a
>  > > content graph of
>  > >
>  > > 	+A-B-C-D+
>  > > 	|-------|
>  > >
>  > > which would be disallowed by the authoritative DPS since a
>  > > loop does not make
>  > > any sense in terms of distributing content.
>  > >
>  > > Is that true?
>  > >
>  >
>  > Close, but not accurate. The DPS does not determine the
> topology. It only
>  > associate
>  > an encoding point in the cumulative path. The point here, is that any
>  > traversal on the
>  > tree can be expressed in a unique way.
>  >
>  > So the DPS does not restrict the topology.
>  >
>
> OK. Who is choosing if topology I.) or II.) is used and when? Can
> a content
> tree have loops? If no (that's what I am assuming) which system
> is preventing
> them and how?
>
>
>  > > What I meant "deals not very well with CDN failures" was now that
>  > > if the DPS has chosen topology I.) early on a failure of
>  > > CDN B will be preventing the use of CDN C and D, while
>  > > topology II does still allow the use of CDN C even if CDN B fails.
>  > > (I think this is also the direction Hillary's comment is targeting.)
>  > >
>  > > You could now argue that the DPS would recover from this
>  > > failure by choosing another content tree. This is what
>  > > I call an atomic update since all participants
>  > > have to have the same view of the content tree to
>  > > prevent request routing loops (since routing is a path
>  > > in the content tree). It actually uses CDN A's CDP as
>  > > arbiter to administer that update.
>  > >
>  > > Does my terminology makes more sense now or am I still off?
>  > >
>  >
>  > The RRS (not DPS) is the entity that determine the direction tree.
>  > yes, CDNs that peer content will have the same view of the
> content tree.
>
>
> OK. So you are suggesting an arbiter. Right? (Similar to Brad's
> proposal.) Brad also suggested other ways on arriving
> at the same view of a tree, therefore, I am just trying
> to understand how you determine the common view in the presence
> of faults and delays.
>
>  >
>  > > If I make sense this solution has similar drawbacks as the
>  > > arbiter solution proposed by Brad. I guess we would have
>  > > to agree if it is a requirement to reveal all current
>  > > business relationships to the authoritative CDN for
>  > > a particular piece of content. There was some opposition
>  > > to that idea during the IETF meeting.
>  > >
>  > > Oliver
>  > >
>  >
>  >
>  > Here, I disagree, the main point of the appraoch is that the
> content tree is
>  > viewed (avialable to the CDNs) by
>  > the participating CDNs, but the way that the redirection tree
> is computed is
>  > totaly private.
>  >
>  > No business realtionships are revealed or any thing else.
>  >
>
> You just mentioned above that everybody has to have the same view of
> the content tree. This by definition reveals the relationships
> represented in the content tree. This is not necessary, but sufficient.
>
> Oliver
>