[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 11:37:17 -0400
Cc: cdn@ops.ietf.org
Delivery-date: Mon, 02 Apr 2001 09:17:05 -0700
Envelope-to: cdn-data@psg.com

Title: RE: hard questions: request routing

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>
>
>

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