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

RE: hard questions: request routing



Title: RE: hard questions: request routing


> -----Original Message-----
> From: Oliver Spatscheck [mailto:spatsch@research.att.com]
> Sent: Tuesday, April 03, 2001 11:04 AM
> To: Barbir, Abbie [CAR:CC70:EXCH]
> 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
>


ok, i see your point. but i can still solve the problem, because, i can just make the
graph as global (no tree)

abbie