[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: hard questions: request routing
Mark,
I intended to provide a summary of the three solutions
which I think are still under consideration as soon as I completely
understand Abbie's proposal. I guess we then have to make a choice
and document it in the appropriate requirements.
Oliver
Mark Day writes:
> 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
> >
>
>