Subject: [CDNi] Content Adaptation

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 28 Oct 2011 11:49:17 +0200

Folks,

Speaking as a co-chair.

I have been through the recent exchange on content adaptation (aka the poorly-titled "Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt" thread) and wanted to share a few thoughts.

First, some messages might have given the impression that content adaptation was required for a CDNI solution to be able to deal with multiple types of terminal/resolution/sizes etc. So at the risk of restating the obvious, let's be very explicit that this is obviously not the case. A very simple/common way to support multiple types of terminal/resolution/sizes in one CDN, or in a multi-CDN environment, is to have different contents/URIs for each profile.
So content adaptation is not _required_ to be supported by CDNI, but is a candidate optimisation to do some of the same things in a different way.

Second, some messages suggested that content adaptation was a very strong win (aka transfer 1 flow instead of 10 flows across CDNs). As Richard pointed out already, this ignores a number of considerations such as the cost associated with performing the actual content adaptation downstream. Anyways, I think content adaptation may be better seen as a trade-off that can indeed be positive in some environments, rather than an obvious huge win.
Also, without the content adaptation optimization, while the content maybe passed across CDNs multiple times (in different formats), it is worth noting that the smaller res/size/quality representations may actually amount to much smaller size/bandwidth than the highest res/size/quality, so it is not quite a multiplying factor. 
Lastly, while the content adaptation optimization may reduce further the inter-CDN transfer from 1-10 flows down to  1 flow, the base CDNI solution allows a content to be transferred across CDNS 1-10 times total instead of once per user accessing the content (as would be the case if the uCDN pumps the same traffic to every users because it cannot interoperate with the dCDN) which can result in a gain factor of 10s, 100s, 1000s,.....

I have the impression that the key arguments have now been exposed (some of them even repeatedly) through the long thread. So I would suggest to pause that discussion, unless _new_ arguments need to be brought into the discussion, and then we can poll for consensus in Taipei and then on the list.

Thanks

Francois

PS: Please think of using specific Subject lines for the various threads and don't hesitate to branch off with a different "Subject" when an initial thread morphs into a different topic. This helps the discussion.

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 28 Oct 2011 13:06:59 +0000

I agree with Francois, both as co-chair and an individual. :)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur
Sent: Friday, October 28, 2011 5:49 AM
To: [email-masked]
Subject: [CDNi] Content Adaptation

Folks,

Speaking as a co-chair.

Thanks

Francois

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 28 Oct 2011 07:38:58 -0700

Hi Francois,

Another factor is the DSP resources required to do content translation
downstream in multiple dCDN's, versus upstream only at one place the uCDN,
assuming a fan-out.

Thanks,
Vishwas
On Fri, Oct 28, 2011 at 2:49 AM, Francois Le Faucheur <[email-masked]>wrote:

> Folks,
>
> Speaking as a co-chair.
>
> I have been through the recent exchange on content adaptation (aka the
> poorly-titled "Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt"
> thread) and wanted to share a few thoughts.
>
> First, some messages might have given the impression that content
> adaptation was required for a CDNI solution to be able to deal with multiple
> types of terminal/resolution/sizes etc. So at the risk of restating the
> obvious, let's be very explicit that this is obviously not the case. A very
> simple/common way to support multiple types of terminal/resolution/sizes in
> one CDN, or in a multi-CDN environment, is to have different contents/URIs
> for each profile.
> So content adaptation is not _required_ to be supported by CDNI, but is a
> candidate optimisation to do some of the same things in a different way.
>
> Second, some messages suggested that content adaptation was a very strong
> win (aka transfer 1 flow instead of 10 flows across CDNs). As Richard
> pointed out already, this ignores a number of considerations such as the
> cost associated with performing the actual content adaptation downstream.
> Anyways, I think content adaptation may be better seen as a trade-off that
> can indeed be positive in some environments, rather than an obvious huge
> win.
> Also, without the content adaptation optimization, while the content maybe
> passed across CDNs multiple times (in different formats), it is worth noting
> that the smaller res/size/quality representations may actually amount to
> much smaller size/bandwidth than the highest res/size/quality, so it is not
> quite a multiplying factor.
> Lastly, while the content adaptation optimization may reduce further the
> inter-CDN transfer from 1-10 flows down to  1 flow, the base CDNI solution
> allows a content to be transferred across CDNS 1-10 times total instead of
> once per user accessing the content (as would be the case if the uCDN pumps
> the same traffic to every users because it cannot interoperate with the
> dCDN) which can result in a gain factor of 10s, 100s, 1000s,.....
>
> I have the impression that the key arguments have now been exposed (some of
> them even repeatedly) through the long thread. So I would suggest to pause
> that discussion, unless _new_ arguments need to be brought into the
> discussion, and then we can poll for consensus in Taipei and then on the
> list.
>
> Thanks
>
> Francois
>
> PS: Please think of using specific Subject lines for the various threads
> and don't hesitate to branch off with a different "Subject" when an initial
> thread morphs into a different topic. This helps the discussion.
>
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>
>

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 23:36:23 +0100

Hi

in draft-stephan-cdni-usecases-metadata-00 we identify situations which require the support and the activation of RRi, Ca or Log features either on the fly or in batch. Their selection and their activation require information from the control interface (examples: Mi, RRi, Ca, Log server's addresses) and from the metadata interface (example: content distribution policies). We made some assumptions  on the bootstrapping and then considered that the elements of information of the control interface were present in the  metadata objects too (examples: purge_mode flag, CAi server for an specific option of a feature ...).   

In fact there is a big overlapping between these 2 interfaces. Section 4.5 of draft-davie-cdni-framework-00 and  section 5 of draft-caulfield-cdni-metadata-core-00 identify the same open issue.

Hence I propose the following: 

-          The control interface is split in 2 parts: 

o   bootstrapping of the CDN interconnexion;

o   control of the contents distribution;

-          The control of the contents distribution and the Metadata interface share the same framework (datamodel parts, protocols...);

-          The framework document specifies precisely the bootstrapping operations and the framework;

Regards

Emile

De : [email-masked] [mailto:[email-masked]] De la part de Woundy, Richard
Envoyé : vendredi 28 octobre 2011 15:07
À : Francois Le Faucheur; [email-masked]
Objet : Re: [CDNi] Content Adaptation

I agree with Francois, both as co-chair and an individual. J

Folks,

Speaking as a co-chair.

Thanks

Francois