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

"Francois Le Faucheur (flefauch)" <flefauch@cisco.com> Mon, 05 November 2012 23:34 UTC

Return-Path: <flefauch@cisco.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAD021F8748 for <cdni@ietfa.amsl.com>; Mon, 5 Nov 2012 15:34:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.572
X-Spam-Level:
X-Spam-Status: No, score=-9.572 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gisdSI9GNwqy for <cdni@ietfa.amsl.com>; Mon, 5 Nov 2012 15:34:11 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 68DFE21F8747 for <cdni@ietf.org>; Mon, 5 Nov 2012 15:34:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9519; q=dns/txt; s=iport; t=1352158451; x=1353368051; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kBjhGzKa2MZ3YTjhm2j/NizHAK78uYE5xQTcGjn2IkQ=; b=UH2+BLQGLRly0XrJfGavgrZmfVfajX6LKaD1qI0NQUCC827FLuiVuRs7 fczlPYfUJmM8Hkaw+WViEuq8VhwWausuPCb8SUwKFRIRWejza/EF9K2+Y L3wOJBhf1D87M60sZGK4+dZ3Z4V7nTOcYTL08yeTbJDEwb4oxIyMnX25U 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuUFAIFMmFCtJXHA/2dsb2JhbABEgkmDTqsqiQEBh3N9gQiCHwEBBBIBWQgFEAIBKiICAjAlAgQBDQ0TB4doC5p+jSIIkmyLfCCDW4FDNmEDkkgFhEqNPYFrgmINgVwfHg
X-IronPort-AV: E=Sophos; i="4.80,718,1344211200"; d="scan'208,217"; a="139082540"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2012 23:33:57 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA5NXuRT019360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 23:33:56 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 17:33:56 -0600
From: "Francois Le Faucheur (flefauch)" <flefauch@cisco.com>
To: ramki Krishnan <ramk@Brocade.com>, 陈戈 <cheng@gsta.com>, "Bhumip.Khasnabish@zte.com.cn" <Bhumip.Khasnabish@zte.com.cn>, "li.mian@zte.com.cn" <li.mian@zte.com.cn>
Thread-Topic: Comments on Long Tail personalized content delivery over CDN Interconnections
Thread-Index: AQHNu64FLac022V2MkGBV8RkMFDU+g==
Date: Mon, 05 Nov 2012 23:33:55 +0000
Message-ID: <FC236DA6F2DA77449EF2D02DF4471A8D202253@xmb-rcd-x10.cisco.com>
References: <C7634EB63EFD984A978DFB46EA5174F2BD6D6D69F0@HQ1-EXCH01.corp.brocade.com>
In-Reply-To: <C7634EB63EFD984A978DFB46EA5174F2BD6D6D69F0@HQ1-EXCH01.corp.brocade.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.65.46]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004
x-tm-as-result: No--46.984100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D202253xmbrcdx10ciscocom_"
MIME-Version: 1.0
Cc: "cdni@ietf.org" <cdni@ietf.org>
Subject: [CDNi] Comments on Long Tail personalized content delivery over CDN Interconnections
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cdni>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2012 23:34:12 -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