Subject: [CDNi] Comments on Long Tail personalized content delivery over CDN Interconnections

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 5 Nov 2012 23:33:55 +0000

Hello,

(As an individual):

I was still very unclear on whether there is a real issue to solve here:
* this seems to suggest a long chain of event whose net result is to ensure uCDN does not redirect long tail content to dCDN (i.e. dCDN performs some distributed content tracking, applies one analysis, then signals to uCDN to not redirect) while the uCDN is actually in a fairly good position in the first place to decide to not redirect content until it is deemed popular
* this seems to equate the fact that a request is redirect to the dCDN with the fact that the content is necessarily consuming valuable storing resources in the dCDN. There are a lot of smart things the dCDN can do to manage storage space efficiently (e.g. store but discard if content in not popular and storage is needed -aka low popularity eviction, not store on first occurrence, redirect long tail content to a smaller set of caches ..).
So I am not convinced there is much benefits to be gained at all over a solution combining smart rerouting logic in uCDN and smart caching in dCDN.

I am not sure the proposed technique addresses all situations. For example, let's say that the dCDN determines at some stage that a given content is not popular and communicates this to uCDN who stops redirecting to dCDN. But then the content becomes popular again. Since the dCDN never receives corresponding request, it cannot determine that the content is now popular and cannot signal to the uCDN to restart redirecting request to dCDN. If you assume that the uCDN is mart enough to keep track of what is popular or not, then it may as well simply use that in the first place to decide when to redirect (or not) to the dCDN and we do not need any extra mechanism.

I am very unclear on whether the proposed solution actually fits the CDNI framework.:
The document seems to assume a different model to how the CDNI Working Group specs are shaping up.
For example, it says:
"Metadata interface requirement
     The CDNI Metadata Distribution interface shall provide indication
     by the dCDN to the uCDN whether the content should be cached or
     not cached in the dCDN. This information should be on a per URL
     basis. The default behavior would be to cache the content in the
     dCDN"
while the CDNI Metadata interface allows to distribute metadata in the opposite direction (i.e. uCDN provides info to dCDN).
I recommend you review more carefully the Framework and Metadata documents.

Cheers

Francois

On 8 Sep 2012, at 10:35, ramki Krishnan wrote:

All,

Thanks for the comments so far. A latest version of the draft is posted athttp://datatracker.ietf.org/doc/draft-krishnan-cdni-long-tail/. Kindly review and comment.

thanks, ramki