Re: Just a discussion proposal

[Eric Dean <eric@crystalballinc.com>]

Wow, very informative message.  I have well thought about these issues.

However, CDNs are not restricted to only "open public" use. i.e. Internet.  
For the Internet, content is ubiquitous and open to all.  CDN's merely 
speed things up..at least to the last mile.

Within VPN or Extranet environments, policy control can be a very 
important issue.  For example, I met with an Airplane company whose 
mechanics often downloads schematics for braking, engine, and other 
systems to these wireless PADs.  To download from "headquarters" a 
high-res 3MB file can often take as much as 20 minutes...meanwhile there's 
a plane full of angry passengers.

Now, being on a wireless network at an airport, they need to be a bit 
sensitive towards who is able to access their intellectual property 
systems.  In fact, I have argued, since Day 1 in Boston, that CDN require 
the full control that HTTP headers et al provide.  In order to guarantee 
that the security and control resides within the CDN operator's hands.

Peering may occur between departments, in a directory heirarchy, between 
a server and a CDN, or in a variety of fashions...however, I seem much of 
the opprtunity being in a business-to-business partner/client, 
supplier/customer application rather than accelerating porn or banner ads.
   
On Thu, 11 Jul 2002, AGOSTINI Pierre FTRD/DMI/CAE wrote:

> 
> > Hi all,
> > 
> 	Unfortunately, we will not be present next week to the IETF meeting however we have to submit a potential subject of discussion.
> 
> > I am responsible of the different works and studies on CDN in France Telecom R&D. Since several years we are working with different operational entities of France Telecom group on the subject. 
> > As France Telecom is a large group, it could be possible to find in the future several entities with a CDN offer.
> > So we could have to implement a kind of internal peering.
> > 
> > Consequently, we have studied the previous drafts in this group. We think that these drafts give good technical proposals but don't take into account the financial, marketing and politic problems with the content peering enough.
> > 
> > First point could be: why will an entity, having its own CDN, do peering with another? Some answers are:
> > 	- to cover black zones (i.e. countries were entity's CDN have no POP)
> > 	- to significantly improve end-users QoS, knowing that this improvement has a cost (shared revenues,...)
> > 	- to reduce costs (local bandwidth should be cheaper than international bandwidth)
> > 	- to be able to share load if CDN becomes overloaded for some reasons
> > 
> > From our point of view, the "black box" concept implies some limitations that will be hardly accepted.
> > As an example, nobody could accept to push its contents or redirect the end-users towards another company's network with no other QoS guarantee than confidence.
> > It is already the case between entities of a same group, so it is not thinkable between two different companies.
> > In the same order of idea, an entity won't accept to do content peering if end-user QoS improvement is about 5% with a revenue share of 50%, or if time to last byte is improved by 50% but original time was around milliseconds. 
> > 
> 	For a Telecom operator, an entity with a CDN could accept to direct a surfer towards another CDN only if it is sure that the searched content is available on a "good" surrogate in this second CDN and if it is sure that the surfer will be satisfied with a best QoS than using its own CDN.
> 
> > Moreover, it will accept to pay this service only if it has a way to verify that the surfer has been best satisfied than with its own CDN, or on some cases if it has the whole control of the content routing (for its content of course) and has decided itself on which surrogate to redirect the surfer. This can be really necessary if two peers choose a different routing algorithm, for example one based on DNS and the other based on HTTP. 
> > 
> > For us, the content peering system has:
> > - to allow each CDN owner to see all surrogates (or POPs) of another peer: A CDN can be interested by using only a part of the surrogates of a peer if they increase its coverage. (In a black box system, any surrogate can serve it without real QoS improvement regarding originated CDN). Doing this, it allows first CDN to choose routing algorithm: delegation or not (including some financial criteria).
> > - to allow each CDN owner to know the surrogates and network load of another peer: it is required to determine if it is interesting to direct a request towards another CDN or not. By this way, each CDN peer assumes its responsibility if it direct a request towards another peer,
> > - to be able to guarantee the time to push or refresh contents on each surrogate: It implies access rights to the distribution system and a standardization of the associated supervision,
> > - to upload logs of delegated requests to determine the QoS of each CDN peer,
> > - ...
> > 
> > 
> > For that, a first step could be to standardize load measurement methods and metrics, scalable protocol to exchange load information, content management information and linked protocols, .... As a consequence, it will then be possible to share CDN Pops between different CDNs.> 
> > 
> > Consequently, peering agreement could be limited to a part of each CDN. A CDN peer could decide to use only a subset of the surrogates of another CDN. Then the second CDN peer has to define a "virtual CDN" or "subCDN", which can be used by the first CDN peer. The second peer has to provide a real-time state of the load (network and host) of this global subCDN or of each surrogate using standard metrics. So the first peer can use these data to compare them with its metrics and choose if the requests have to be direct towards the second CDN. Then, a supervision function has to allow verifying that the requests have been satisfied with the awaited QoS.
> > 
> > Another way could be to build a solution presupposing that an independent third party exists, able to supervise and manage all the CDN peers and to give some guarantees on the QoS of each CDN.
> > 
> > Sorry to only send some general idea but I hope that they will imply some reactions.
> > 
> > Good meeting and best regards
> > 
> > Pierre
> > 
> > 
> 

--