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

RE: hard questions: request routing

To: Oliver Spatscheck <spatsch@research.att.com>
Subject: RE: hard questions: request routing
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
Date: Mon, 2 Apr 2001 14:10:44 -0400
Cc: cdn@ops.ietf.org
Delivery-date: Mon, 02 Apr 2001 11:39:51 -0700
Envelope-to: cdn-data@psg.com

Title: RE: hard questions: request routing

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
> > > >
> > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > > > <HTML>
> > > > <HEAD>
> > > > <META HTTP-EQUIV="Content-Type" CONTENT="text/html;
> > > charset=iso-8859-1">
> > > > <META NAME="Generator" CONTENT="MS Exchange Server version
> > > 5.5.2654.19">
> > > > <TITLE>RE: hard questions: request routing</TITLE>
> > > > </HEAD>
> > > > <BODY>
> > > > 
> > > >
> > > > see rmarks inside,
> > > > 
> > > >
> > > > > -----Original Message-----
> > > > > From: Oliver Spatscheck [<A
> > > HREF=""mailto:spatsch@research.att.com">mailto:spatsch@research
> > > .att.com</A>]
> > > > > 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)
> > > > > > SIZE=2>         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.
> > > > > > SIZE=2>         &
> > > nbsp;  - can justify that very easily
> > > > > > SIZE=2>         &
> > > nbsp;  - this also include the life span of the
> > > retaionship for that content.
> > > > > > SIZE=2>         &
> > > nbsp;  - mathematically speaking, this parameter
> > > determines the number of content
> > > > > > SIZE=2>         &
> > > nbsp;    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
> > > > 
> > > >
> > > > </BODY>
> > > > </HTML>
> > >
> > >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > <HTML>
> > <HEAD>
> > <META HTTP-EQUIV="Content-Type" CONTENT="text/html;
> charset=iso-8859-1">
> > <META NAME="Generator" CONTENT="MS Exchange Server version
> 5.5.2654.19">
> > <TITLE>RE: hard questions: request routing</TITLE>
> > </HEAD>
> > <BODY>
> > 
> >
> > 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 [<A
> HREF=""mailto:spatsch@research.att.com">mailto:spatsch@research
> .att.com</A>]
> > > 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 [<A
> HREF=""mailto:spatsch@research.att.com">mailto:spatsch@research
> .att.com</A>]
> > >  > > 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.
> > > 
> >         &nbs
> p;   - can justify that very easily
> > > 
> >         &nbs
> p;   - this also include the life span of the 
> > > retaionship for that
> > >  > content.
> > > 
> >         &nbs
> p;   - mathematically speaking, this parameter 
> > > determines the number
> > >  > of content
> > > 
> >         &nbs
> p;     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
> > >  > 
> > >  > <!DOCTYPE HTML PUBLIC
> "-//W3C//DTD HTML 3.2//EN">
> > >  > <HTML>
> > >  > <HEAD>
> > >  > <META
> HTTP-EQUIV="Content-Type" CONTENT="text/html; 
> > > charset=iso-8859-1">
> > >  > <META
> NAME="Generator" CONTENT="MS Exchange Server
> version 
> > > 5.5.2654.19">
> > >  > <TITLE>RE: hard
> questions: request routing</TITLE>
> > >  > </HEAD>
> > >  > <BODY>
> > >  > 
> > >  > 
> > >  > SIZE=2>see rmarks inside,
> > >  > 
> > >  > 
> > >  > SIZE=2>&gt; -----Original Message-----
> > >  > SIZE=2>&gt; From: Oliver Spatscheck [<A 
> > > HREF=""<A"
> HREF=""mailto:spatsch@research.att.com">mailto:spatsch@research
> .att.com</A>"><A
> HREF=""mailto:spatsch@research">mailto:spatsch@research</A>
> > > .att.com</A>]
> > >  > SIZE=2>&gt; Sent: Friday, March 30, 2001 4:12
> PM
> > >  > SIZE=2>&gt; To: Barbir, Abbie
> [CAR:CC70:EXCH]
> > >  > SIZE=2>&gt; Cc: cdn@ops.ietf.org
> > >  > SIZE=2>&gt; Subject: RE: hard questions: request 
> > > routing
> > >  > SIZE=2>&gt; 
> > >  > SIZE=2>&gt; 
> > >  > SIZE=2>&gt; 
> > >  > SIZE=2>&gt; 
> > >  > SIZE=2>&gt; Abbie,
> > >  > SIZE=2>&gt; 
> > >  > SIZE=2>&gt;
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I am 
> > > a littel bit confused about what
> exactly your are
> > >  > SIZE=2>&gt; proposing. Let me try an example for 
> > > a DNS based RRS:
> > >  > SIZE=2>&gt; 
> > >  > SIZE=2>&gt; - The domain is www.foobar.com
> > >  > SIZE=2>&gt; - The authoritative RRS is CDN
> A
> > >  > SIZE=2>&gt; - The content has been distributed 
> > > to CDN A, B and C
> > >  > 
> > >  > 
> > >  > SIZE=2>&lt;&lt;&lt;&lt;&lt;&lt;&amp
> ;nbsp; well, that 
> > > mean that the content was
> distributed by the DPS. The senario 
> > > is as follows:
> > >  > SIZE=2>&nbsp;- Content provider distribute to 
> > > CDN A (only one CDN for
> now)
> > >  > SIZE=2>&nbsp;- CDN A RRS is Authoritative on 
> > > that content
> contentA.cdna.com
> > >  > SIZE=2>&nbsp;- CDN A know resell the content to 
> > > CDN B
> > >  > SIZE=2>&nbsp;&nbsp; - the new content is 
> > > xxxx????.cdnB.com
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - CDN B
> RRS is 
> > > autoratative on that new
> content
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - ALL RRS
> in the 
> > > system must be informed about
> that.
> > >  > SIZE=2>&nbsp;&nbsp; - Hence, at the moment that 
> > > CDN A has agreed to sell to CDN B,
> the content 
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; path has an 
> > > extra hop in it, let us call it
> content hop.
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; - hence,
> the 
> > > distribution system can inform the
> RRS about that
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&a
> mp;nbsp; - a 
> > > content routing matrix can be
> updated in the RRS (based on 
> > > content only)
> > >  > 
> > >
> SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&a
> mp;nbsp;&nbsp;&nbsp; after 
> > > the DPS system has finalized the
> tranaction. (see more about 
> > > at the end)
> > >  > 
> > >  > 
> > >  > SIZE=2>&nbsp; - CDN B now resell the content to 
> > > CDN B
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp; - DPS inform all RRS 
> > > about that
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> - new 
> > > content is
> blablabla.CDNC.com
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> - content 
> > > routing matrix is updated with the
> info.
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> - RRS in 
> > > CDN C is authorartive on
> blablabla.CDNC.com.
> > >  > 
> > >  > 
> > >  > 
> > >  > SIZE=2>basically, here is the structure of the 
> > > proposed solution.
> > >  > 
> > >  > 
> > >  > SIZE=2>Assumptions:
> > >  > 
> > >  > 
> > >  > SIZE=2>a. For a CDN to peer it must acquire a 
> > > number
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp; (can be based on BGP, 
> > > or issued by an organization such as
> CA)
> > >  > SIZE=2>b. Peering of content must be done on the 
> > > fly. This means that when the
> DPS
> > >  > SIZE=2>&nbsp;&nbsp; finished negotating the 
> > > peering of content, the RRS (DNS at
> least) system must be 
> > >  > SIZE=2>&nbsp;&nbsp; updated instantly to reflect 
> > > the authorartive CDN. Thus, no delay
> is allowed for the
> > >  > SIZE=2>&nbsp;&nbsp; regular DNS system 
> > > propgation etc.
> > >  > SIZE=2>C. From step b, there may be a need (not 
> > > really mandatory, optional) for the
> same
> > >  > SIZE=2>&nbsp;&nbsp; organization to assume a 
> > > structure for the&nbsp; peering
> DNS. For example, let us 
> > > assume that 
> > >  > SIZE=2>&nbsp;&nbsp; peering.com is controlled by 
> > > that orgatization.
> > >  > SIZE=2>&nbsp;&nbsp; - all peered content will be
> 
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> > >
> blablabla!!!!!!!!!.peering.com
> > >  > SIZE=2>&nbsp;&nbsp; - update regarding 
> > > autorartive content is thus done
> between the RRS as opposed
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; to
> propgating 
> > > across the DNS hireachy.
> > >  > 
> > >  > 
> > >  > SIZE=2>Solution:
> > >  > 
> > >  > 
> > >  > SIZE=2>1- The number of times content can be 
> > > resold (peered) is negotatied in the
> DPS system and is
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp; specified by the 
> > > original content
> provider.
> > >  > 
> > >
> SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&a
> mp;nbsp;&nbsp;&nbsp;&nbsp;&
> > > nbsp;&nbsp; - can justify that
> very easily
> > >  > 
> > >
> SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&a
> mp;nbsp;&nbsp;&nbsp;&nbsp;&
> > > nbsp;&nbsp; - this also include
> the life span of the 
> > > retaionship for that
> content.
> > >  > 
> > >
> SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&a
> mp;nbsp;&nbsp;&nbsp;&nbsp;&
> > > nbsp;&nbsp; - mathematically
> speaking, this parameter 
> > > determines the number of
> content
> > >  > 
> > >
> SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&a
> mp;nbsp;&nbsp;&nbsp;&nbsp;&
> > > nbsp;&nbsp;&nbsp;&nbsp;
> hops in the content routing (no layer 
> > > 3 here at all)tree.
> > >  > 
> > >  > 
> > >  > SIZE=2>2- Hence, from this point, we can 
> > > determine all the
> > >  > SIZE=2>&nbsp;&nbsp; possible number of CNAMEs 
> > > associated with that content (number
> not value).
> > >  > SIZE=2>&nbsp;&nbsp; This is done in the form of 
> > > a Content Routing Matrix (CRM) that
> each participating 
> > >  > SIZE=2>&nbsp;&nbsp; CDN will have.The CRM matrix 
> > > is basically a collection of all
> possible CNAMEs 
> > >  > SIZE=2>&nbsp;&nbsp; associated with that 
> > > content. The entries in it are
> mapped to the CDN numbers 
> > >  > SIZE=2>&nbsp;&nbsp; after the successful 
> > > DPS&nbsp; negotation.
> > >  > 
> > >  > 
> > >  > SIZE=2>3- Every time the DPS system peer the 
> > > content, the CRM matrix is updated
> by the RRS system
> > >  > SIZE=2>&nbsp;&nbsp; whereby, the CDN number is 
> > > inserted in the corresponding entry
> in the CRM matrix.
> > >  > SIZE=2>&nbsp;&nbsp; - these entries are used in 
> > > the redirection process.
> > >  > 
> > >  > 
> > >  > SIZE=2>4- CRM matrix life span is determined by 
> > > the DPS system.
> > >  > 
> > >  > 
> > >  > 
> > >  > SIZE=2>This approach basically decouples layer 3 
> > > from the content routing
> layer.
> > >  > SIZE=2>I will be writing a detailed description 
> > > (with examples) about this apprach
> pretty soon.
> > >  > 
> > >  > 
> > >  > SIZE=2>PS: layer 3 infor and other metrics 
> > > including content metrics are used
> to decide which
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp; CDN the RRS must 
> > > direct to. The appracoh keeps track
> of content hops (only)
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp; - The approach can be 
> > > easily integrating with the
> accounting system for billing
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> purposed. 
> > > (all hops are part of the CNMAE,
> that are known at resolution 
> > > time)
> > >  > SIZE=2>&nbsp;&nbsp;&nbsp; - CNAMEs for aggrgate 
> > > content can be easily
> incorpotated.
> > >  > 
> > >  > 
> > >  > SIZE=2>PS: these are the concepts for know. I 
> > > still need more refinment. Feedback
> is welcomed.
> > >  > 
> > >  > 
> > >  > 
> > >  > SIZE=2>abbie
> > >  > 
> > >  > 
> > >  > </BODY>
> > >  > </HTML>
> > > 
> > > 
> > 
> >
> > </BODY>
> > </HTML>
>

Prev by Date: RE: hard questions: request routing
Next by Date: RE: hard questions: request routing
Prev by thread: RE: hard questions: request routing
Next by thread: RE: hard questions: request routing
Index(es):
- Date
- Thread