[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: hard questions: request routing
Consider the graph of content nodes. For each metric, there is
an optimal tree embedded in that graph. But, there is no guarantee
that there is one embedded tree that contains the optimal
tree for every metric. That's not an indictment of the scheme,
just a cautionary note.
It is interesting to task a single system with the responsibility for
creating the content tree for each of its content sets. Still, that
seems like a lot of tree distributions transactions, potentially.
Hilarie
"Abbie Barbir" <abbieb@nortelnetworks.com> 04/02/01 12:10PM >>>
hi all,
Regarding the loop prevention problem, it seems to me that the discussion is
coupling the
redirection method with routing content.
The two issues must be seperated. For content routing, the following must
hold:
1. A content hop represents a content path between one CDN to another
2. The path info is cumulative.
3. A content tree is formed. Each leaf in the tree encodes the path to that
leaf.
Metrics are used to traverse the tree. A direction tree represents a
specific traversal
of the content tree. The traversal method is decided by the directing CDN
based on
some metric(s).
These metrics can be
- on line
- off line (SLA based)
By property 3 above, the redirection tree is guranteed to be loop free. The
process
of traversing the content tree is properietory. There is no need to restrict
on one metric
etc.. .
It can be proven that the redirection tree is a spcial ordering of the
content tree for a given set of metrics. The odering process does not
destroy the property of the leaf (representing the path to it).
The process of selecting the best surrogate represents that ordering of the
tree.
abbie
> -----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.
>
> 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
>
>
> Abbie Barbir writes:
> >
> > Oliver,
> >
> > In the proposed approach, the only update is done after
> the DPS system has
> > negotaited the peering of content (that's all)
> >
> > Can you please stop thinking in terms of layer 3. The
> proposed solution is
> > not dependent on any leyer 3.
> >
> > I think it is about time to start thinking of content
> peering as content
> > routing at layer (8).
> >
> >
> > Keep in mind the following:
> > 1. we need a content tree (not related to any network)
> > 2. Layer 3 are only used for decision purposed (pick the
> right CNAME, that's
> > it)
> >
> >
> > abbie
> >
> >
> > > -----Original Message-----
> > > From: Oliver Spatscheck [mailto:spatsch@research.att.com]
> > > Sent: Monday, April 02, 2001 11:24 AM
> > > To: Barbir, Abbie [CAR:CC70:EXCH]
> > > Cc: cdn@ops.ietf.org
> > > Subject: RE: hard questions: request routing
> > >
> > >
> > >
> > >
> > >
> > > Abbie,
> > >
> > > if I understand your solution right you are solving the
> > > problem by requiring global atomic updates of the metric used to
> > > decide which CDN to use. Since this metric should be
> load dependent
> > > and, therefore, is updated frequently you are suggesting a
> > > frequent distributed atomic update. This is a very expensive
> > > operation in the presence of faults (network partitioning,
> > > CDN's not responding, packets being lost). This is
> > > why BGP for example does not use a global atomic update and
> > > rather allows for transient loops.
> > >
> > > I still would vote for the three level restriction outlined
> > > in my other email to avoid this complexity for now.
> > >
> > > Oliver
> > >
> > >
> > > Abbie Barbir writes:
> > > >
> > > > see rmarks inside,
> > > >
> > > > > -----Original Message-----
> > > > > From: Oliver Spatscheck [mailto:spatsch@research.att.com]
> > > > > Sent: Friday, March 30, 2001 4:12 PM
> > > > > To: Barbir, Abbie [CAR:CC70:EXCH]
> > > > > Cc: cdn@ops.ietf.org
> > > > > Subject: RE: hard questions: request routing
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Abbie,
> > > > >
> > > > > I am a littel bit confused about what exactly your are
> > > > > proposing. Let me try an example for a DNS based RRS:
> > > > >
> > > > > - The domain is www.foobar.com
> > > > > - The authoritative RRS is CDN A
> > > > > - The content has been distributed to CDN A, B and C
> > > >
> > > > <<<<<< well, that mean that the content was distributed
> > > by the DPS. The
> > > > senario is as follows:
> > > > - Content provider distribute to CDN A (only one CDN for now)
> > > > - CDN A RRS is Authoritative on that content
> contentA.cdna.com
> > > > - CDN A know resell the content to CDN B
> > > > - the new content is xxxx????.cdnB.com
> > > > - CDN B RRS is autoratative on that new content
> > > > - ALL RRS in the system must be informed about that.
> > > > - Hence, at the moment that CDN A has agreed to sell to
> > > CDN B, the
> > > > content
> > > > path has an extra hop in it, let us call it content hop.
> > > > - hence, the distribution system can inform the
> RRS about that
> > > > - a content routing matrix can be updated in the
> > > RRS (based on
> > > > content only)
> > > > after the DPS system has finalized the
> > > tranaction. (see more about
> > > > at the end)
> > > >
> > > > - CDN B now resell the content to CDN B
> > > > - DPS inform all RRS about that
> > > > - new content is blablabla.CDNC.com
> > > > - content routing matrix is updated with the info.
> > > > - RRS in CDN C is authorartive on blablabla.CDNC.com.
> > > >
> > > >
> > > > basically, here is the structure of the proposed solution.
> > > >
> > > > Assumptions:
> > > >
> > > > a. For a CDN to peer it must acquire a number
> > > > (can be based on BGP, or issued by an
> organization such as CA)
> > > > b. Peering of content must be done on the fly. This means
> > > that when the DPS
> > > > finished negotating the peering of content, the RRS
> > > (DNS at least) system
> > > > must be
> > > > updated instantly to reflect the authorartive CDN.
> > > Thus, no delay is
> > > > allowed for the
> > > > regular DNS system propgation etc.
> > > > C. From step b, there may be a need (not really mandatory,
> > > optional) for the
> > > > same
> > > > organization to assume a structure for the peering
> > > DNS. For example, let
> > > > us assume that
> > > > peering.com is controlled by that orgatization.
> > > > - all peered content will be
> > > > blablabla!!!!!!!!!.peering.com
> > > > - update regarding autorartive content is thus done
> > > between the RRS as
> > > > opposed
> > > > to propgating across the DNS hireachy.
> > > >
> > > > Solution:
> > > >
> > > > 1- The number of times content can be resold (peered) is
> > > negotatied in the
> > > > DPS system and is
> > > > specified by the original content provider.
> > > > - can justify that very easily
> > > > - this also include the life span of the
> > > retaionship for that
> > > > content.
> > > > - mathematically speaking, this parameter
> > > determines the number
> > > > of content
> > > > hops in the content routing (no layer 3 here
> > > at all)tree.
> > > >
> > > > 2- Hence, from this point, we can determine all the
> > > > possible number of CNAMEs associated with that content
> > > (number not
> > > > value).
> > > > This is done in the form of a Content Routing Matrix
> > > (CRM) that each
> > > > participating
> > > > CDN will have.The CRM matrix is basically a collection
> > > of all possible
> > > > CNAMEs
> > > > associated with that content. The entries in it are
> > > mapped to the CDN
> > > > numbers
> > > > after the successful DPS negotation.
> > > >
> > > > 3- Every time the DPS system peer the content, the CRM
> > > matrix is updated by
> > > > the RRS system
> > > > whereby, the CDN number is inserted in the
> > > corresponding entry in the CRM
> > > > matrix.
> > > > - these entries are used in the redirection process.
> > > >
> > > > 4- CRM matrix life span is determined by the DPS system.
> > > >
> > > >
> > > > This approach basically decouples layer 3 from the content
> > > routing layer.
> > > > I will be writing a detailed description (with examples)
> > > about this apprach
> > > > pretty soon.
> > > >
> > > > PS: layer 3 infor and other metrics including content
> > > metrics are used to
> > > > decide which
> > > > CDN the RRS must direct to. The appracoh keeps track
> > > of content hops
> > > > (only)
> > > > - The approach can be easily integrating with the
> > > accounting system for
> > > > billing
> > > > purposed. (all hops are part of the CNMAE, that
> are known at
> > > > resolution time)
> > > > - CNAMEs for aggrgate content can be easily incorpotated.
> > > >
> > > > PS: these are the concepts for know. I still need more
> > > refinment. Feedback
> > > > is welcomed.
> > > >
> > > >
> > > > abbie
> > > >
>