Subject: [CDNi] Confirming some IETF-85 decisions

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 21 Nov 2012 10:04:58 +0000

All,

As documented in the minutes, the following decisions were tentatively made at IETF-85:

	* Content Deduplication: The WG will continue the work on this topic inside the WG, but will not aim to support it in first version of the CDNI interfaces.

	* Long Tail Content: The WG will not continue the work on this topic inside the WG for now (at least not as a priority item) and will not aim to support something specific for it in first version of the CDNI interfaces.

	* CDNI Logging: draft-bertrand-cdni-logging is accepted as WG document

We will consider these decisions confirmed unless we hear substantiated objections by 30 Nov.

Cheers

Francois & Rich

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 21 Nov 2012 15:16:12 -0500

Thanks Francois ..

Yes, we'll continue to work on the de-dup draft, and plan to update it
with inputs from other operators for including scenarios like the
ones that Marcin mentioned (use of DRM).
We welcome inputs / feedback / suggestions from others as well.

For LTC draft, Ramki will contact you,  and send further
comments/suggestions.

For the Logging draft, do you know *why Syslog is not the good *
*answer for CDNi requirements* ?

Best.

Bhumip

On Wed, Nov 21, 2012 at 5:04 AM, Francois Le Faucheur (flefauch) <
[email-masked]> wrote:

>         * Content Deduplication: The WG will continue the work on this
> topic inside the WG, but will not aim to support it in first version of the
> CDNI interfaces.
>
>         * Long Tail Content: The WG will not continue the work on this
> topic inside the WG for now (at least not as a priority item) and will not
> aim to support something specific for it in first version of the CDNI
> interfaces.
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

-- 
Best.

Bhumip Khasnabish
[email-masked]
[email-masked]
[email-masked]
+1-781-752-8003 (mobile)
http://tinyurl.com/bhumip

                   __o
             _ `\ <, _
.......... ( • ) / ( • ) ......................

---

From: ramki Krishnan <[email-masked]>
Date: Wed, 21 Nov 2012 12:47:42 -0800

Dear Francois,

We are incorporating the feedback from the meeting (from you, Kevin and others) in coming up with 
(a) more information on relevance of LTC (long-tail content ) to CDNI 
(b) a solution for the LTC problem without any new requirements in the CDNI interfaces. 
 
Our target for the LTC support over CDNI is a best practices draft which provides guidance to vendors and operators on how to manage LTC deliver effectively and efficiently.
 
We expect to send this document out for review in the next 3-4 weeks and request you to continue supporting this as a working group topic.

Thanks, 
Ramki (on behalf of long-tail co-authors)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: Wednesday, November 21, 2012 2:05 AM
To: [email-masked]
Subject: [CDNi] Confirming some IETF-85 decisions

All,

Cheers

Francois & Rich

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 22 Nov 2012 08:10:31 +0000

Hi Bhumip,

On 21 Nov 2012, at 21:16, [email-masked]<mailto:[email-masked]> wrote:

Thanks Francois ..

Good.

Larrry, I also suggest that the cdni-framework document incorporates one paragraph about the concept of content deduplication; something to simply introduce the notion that the exact _same content item from the same content provider_ may end-up being handled by a given CDN through multiple CDN paths and therefore that this can be handled by EITHER handling each instance separately OR by extra control plane smartness to correlate the multiple instances in order to optimize the handling of the multiple instances (e.g. de-deuplicate content).

For LTC draft, Ramki will contact you,  and send further comments/suggestions.

For the Logging draft, do you know why Syslog is not the good
answer for CDNi requirements ?

As noted in the slides presented by Emile about the cdni-logging I-D:
"
– Key decisions remaining need WG input and control:
• Refining of the data model
• SelecRon of the Logging protocol
• SelecRon of the mandatory fields and records
"
the selection of a logging protocol has not been made yet and Syslog is in the list of candidates.
The next version of the draft will start introduce considerations and requirements (scaling, reliability,…) in view of facilitating this discussion.
Input on pros&cons of using Syslog (or other candidate protocols) for CDNI logging is welcome.

Francois

Best.

Bhumip

On Wed, Nov 21, 2012 at 5:04 AM, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:
All,

Cheers

Francois & Rich
_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

--
Best.

Bhumip Khasnabish
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
+1-781-752-8003<tel:%2B1-781-752-8003> (mobile)
http://tinyurl.com/bhumip

                   __o
             _ `\ <, _

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 22 Nov 2012 08:38:33 +0000

Bhumip,

> We welcome inputs / feedback / suggestions from others as well.

One input as an individual:

There are situations where the "same content from the same content provider" ends up being handled by a given CDN via more than one CDN-path (i.e. content Cx from CSPa distributed CSPa-->uCDN1--->dCDN and also distributed CSPa-->uCDN2-->dCDN), and therefore may be referenced by different URIs in that given CDN (dCDN) and therefore appears as different content. I believe the occurrence of that situation is well understood and it is clear that one could optimize that scenario by extra control plane smartness (e.g. to de-deduplicate content storage).

During the Atlanta discussion, it seemed to me that some people just assumed that if the same "content" is distributed by different CSPs (i.e. LatestBlockbuster.mp4 is distributed by CSPa and CSPb) then it can be de-duplicated. I haven't thought extremely hard about that, but my gut reaction is that we absolutely do not want to perform de-duplication in that scenario. While we may have two representations of the same "movie", each CSP representation ought to be considered as the individual CSP asset. If CSPa uses a poor encoder for the given content, I am not sure CSPb would be happy to have that copy of content streamed to his end-users. If CSPb makes a mistake and places the wrong content in his origin server, I am not sure CSPa would be happy to have that copy of content streamed to his end-users. As pointed by Marcin, it is also not possible to deduplicate anyways when DRM is used over the content. 
(note that I am keeping outside of the discussion potential low level opportunistic content deduplication mechanisms that might be performed by a cache that notices that two blocks of apparently independent files happen to be exactly identical)

Whether you include the latter scenarios (i.e. LatestBlockbuster.mp4 distributed by CSPa and CSPb), or not, in your estimation of "content-duplication" opportunities radically affect the figures you will come up with. I suspect this partly explains the disconnect between your figures and Marcin.

Do we agree that the former scenarios (Cx from CSPa distributed CSPa-->uCDN1--->dCDN and also distributed CSPa-->uCDN2-->dCDN) are a clear opportunity for content-deduplication?
Have you made an analysis of the latter scenarios (i.e. LatestBlockbuster.mp4 distributed by CSPa and CSPb) and do you feel these scenarios should be in scope of the CDNI content de-duplication mechanism?
If yes, can you please comment on the few issues I brought up above?

Cheers

Francois