Subject: [CDNi] Comments on draft-jin-cdni-content-deduplication-optimization-01.txt

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 24 Jul 2012 14:29:04 +0000

Hi,

A few comments on draft-jin-cdni-content-deduplication-optimization below.

* in several places, the document discusses separately pre-position versus dynamic acquisition. I don't think there needs to be any difference in the problem or the solution for the two cases. 
The issue is: when a dCDN needs to get a content (whether for pre-position or for dynamic acquisition):
	1) can it avoid re-storing a 2nd copy of same content
	2) can it avoid requesting that 2nd copy.
You may want to consider discussing the problem/solution independently of the acquisition method.

* section 4.3.3 discusses content removal but does not seem to discuss one interesting aspect of content reduplication: when a dCDN ends up storing a given content on behalf of two uCDNs, and then one uCDN triggers content removal but the other one does not, do you remove the content or not?
Can you discuss that topic?

* I was picturing that the Content-ID would be associated to a given content request through the CDNI metadata. In other words, we could define an optional Metadata object containing the Content-ID. Then whenever an action is needed (e.g. content acquisition) for a resource URI, the CDN would first acquire the metadata (as usual) and then get the Content-ID. It can then make the determination on whether the content is already stored.
Is this what you have in mind also?
I got a little confused by this text: "Receiving the message, the dCDN uses the Content Identifier to look up target metadata." This suggests that the metadata are hanging off the Content ID. I think you need to have the metadata hanging off the resource URL, in particular because you need separate metadata per uCDN (even for the same content). And I think the Content-ID is then conveyed inside the content metadata,
Does that make sense ?
 
Cheers

Francois

On 19 Jun 2012, at 05:17, [email-masked] wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : Content De-duplication for CDNi Optimization
> 	Author(s)       : WeiYi Jin
>                          Mian Li
>                          Bhumip Khasnabish
> 	Filename        : draft-jin-cdni-content-deduplication-optimization-01.txt
> 	Pages           : 17
> 	Date            : 2012-06-18
> 
> Abstract:
>   Recent explosive growth of content delivery/distribution networks
>   (CDNs) and their interconnection are causing unintended repetition of
>   content storage in the same dCDN.  This can be avoided by using a
>   suitable de-duplication mechanism.  This document explores the
>   scenarios which create the problems, and then discusses the
>   approaches to eliminate the duplicated transmission of the same
>   content from uCDN(s) to dCDN in CDNi networks.  To implement the
>   optimization, some enhancements to the CDNi metadata model and
>   interface are required.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-jin-cdni-content-deduplication-optimization
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-jin-cdni-content-deduplication-optimization-01
> 
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=draft-jin-cdni-content-deduplication-optimization-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: [email-masked]
Date: Thu, 26 Jul 2012 17:47:29 +0800

Dear Francois,

Thank you for your kind review and comments on content de-duplication 
draft. Please see my feedback below:

1. You are right. The content duplication issue occurs in both 
pre-positioning case and content acquisition case with no difference. The 
content item can be delivered from uCDN to dCDN via either way and then 
requested to download to dCDN again via either way. The solutions for both 
cases are the same. Firstly, the Content-ID is delivered from uCDN to dCDN 
for storage. Secondly, in either pre-positioning procedure or content 
acquisition procedure, before uCDN delivers the acutal content to dCDN, 
Content-ID is exchanged to check the availability of the requested content 
in dCDN. Thirdly, dCDN determines whether to download the actual content 
or not. As for the first point you mentioned below, do you mean this draft 
lists different procedures in section 4.3 for pre-positioning and for 
content acquistion separately? We do not intend to separate the problem 
and the solution. We do so because the pre-positioning procedure and the 
content acquisition procedure are two procedures and we describe them in 
two sub-sections in order to make the description of the solution clearer.

2. As for the content removal, yes, it is an interesting aspect that we 
did not discuss in our proposal. It is our opinion that only the uCDN that 
delivered the content item to the dCDN is proper and is authorized to send 
the removal command to delete the content. Considering that CDN A and CDN 
B are uCDNs of CDN C, CDN A delivers a content item to CDN C via 
pre-positioning procedure or CDN C acquires a content item from CDN A via 
content acquisition procedure. CDN A is authorised to delete the content. 
As for CDN B, re-sending the content will not occur if the solution in 
this draft is applied. So CDN B will not initiate the removal action. How 
do you think?
This is a missing part that we need to clarify in the draft. Thank you for 
pointing it out.

3. Actually as what you explained below is just what we want to propose in 
our draft but we did not make it clear enough. So that makes you confused. 
Content-ID as an optional metadata object, is exactly one important part 
we are proposing. The content-ID is distributed as an optional content 
metadata with/without the actual content item from uCDN to dCDN for 
storage. Then for example, if the uCDN wants to pre-position content 
items, corresponding content-ID and Resource ID are sent in the 
pre-positioning request message from uCDN to dCDN. Then the dCDN can use 
this content-ID as an index to look up its stored metadata information to 
check whether the content item has been stored or not. The content 
acquisition procedure is similar to above one. 
I will make the description clearer in the updated version. Thank you~

"Francois Le Faucheur (flefauch)" <[email-masked]> 写于 2012-07-24 
22:29:04:

> * in several places, the document discusses separately pre-position 
> versus dynamic acquisition. I don't think there needs to be any 
> difference in the problem or the solution for the two cases. 
> * section 4.3.3 discusses content removal but does not seem to 
> discuss one interesting aspect of content reduplication: when a dCDN
> ends up storing a given content on behalf of two uCDNs, and then one
> uCDN triggers content removal but the other one does not, do you 
> remove the content or not?
> * I was picturing that the Content-ID would be associated to a given
> content request through the CDNI metadata. In other words, we could 
> define an optional Metadata object containing the Content-ID. Then 
> whenever an action is needed (e.g. content acquisition) for a 
> resource URI, the CDN would first acquire the metadata (as usual) 
> and then get the Content-ID. It can then make the determination on 
> whether the content is already stored.
> I got a little confused by this text: "Receiving the message, the 
> dCDN uses the Content Identifier to look up target metadata." This 
> suggests that the metadata are hanging off the Content ID. I think 
> you need to have the metadata hanging off the resource URL, in 
> particular because you need separate metadata per uCDN (even for the
> same content). And I think the Content-ID is then conveyed inside 
> the content metadata,
> Does that make sense ?
> 
> Cheers
> 
> Francois
> 
> 
>