From kevin.ma@azukisystems.com Sun Nov 3 20:14:19 2013 Return-Path: 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 AD45221E80F3 for ; Sun, 3 Nov 2013 20:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDYTlH6izocv for ; Sun, 3 Nov 2013 20:14:03 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 60FF021E8089 for ; Sun, 3 Nov 2013 20:14:00 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CA7B38BE949; Sun, 3 Nov 2013 23:13:59 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 34B1F8BE929; Sun, 3 Nov 2013 23:13:59 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Sun, 3 Nov 2013 23:10:50 -0500 From: Kevin J Ma To: "Kent Leung (kleung)" , "cdni@ietf.org" Date: Sun, 3 Nov 2013 23:13:55 -0500 Thread-Topic: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-03.txt Thread-Index: AQHOpbdnaJjbAjfax0ehJTbVgqZ395nBn8bQgFMPuWA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6B027F59C2C@MAILR002.mail.lan> References: <20130830193036.1149.11538.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-03.txt 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 04:14:19 -0000 SGkgS2VudCwNCg0KICBUaGUgdXBkYXRlcyBzaW5jZSBCZXJsaW4gbG9vayBnb29kLg0KDQo+IC0g VVJJIFNpZ25pbmcgVG9rZW4gYXR0cmlidXRlIHJlbmFtZWQgdG8gVVJJIFNpZ25pbmcgUGFja2Fn ZSBhdHRyaWJ1dGUsDQo+IHdoaWNoIGlzIG5vdyBtYW5kYXRvcnkNCg0KICBTb21lIHBhcnRzIG9m IHRoZSBkcmFmdCBzdGlsbCByZWFkIGFzIHRob3VnaHQgcGFja2FnaW5nIGlzIG9wdGlvbmFsPw0K DQogIENvbW1lbnRzL3F1ZXN0aW9ucyBvbiB0aGUgbGF0ZXN0IGRyYWZ0IGJlbG93Lg0KDQp0aGFu eC4NCg0KLS0gIEtldmluIEouIE1hDQoNCmNvbW1lbnRzOg0KDQotIHNlY3Rpb24gMS4zOiBzaG91 bGQgIm5lZWRzIiBiZSBhIFNIT1VMRCBvciBhIE1VU1Q/DQoNCiAgICAiTm90ZSB0aGF0IHRoZSBz aWduZWQgUmVkaXJlY3Rpb24gVVJJDQogICAgIG5lZWRzIHRvIG1haW50YWluIHRoZSBzYW1lIGxl dmVsIG9mIHNlY3VyaXR5IGFzIHRoZSBvcmlnaW5hbCBTaWduZWQNCiAgICAgVVJJLiINCg0KLSBz ZWN0aW9uIDIuMTogZG8gd2Ugd2FudCB0byByZWZlcmVuY2UgdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zDQogICAgICAgICAgICAgICBzZWN0aW9uIHdydCBFVC9DSVAgbGltaXRhdGlvbnM/DQoN Ci0gc2VjdGlvbiAyLjI6IHRoZSBkZWZhdWx0IGhhc2ggZnVuY3Rpb24gU0hBMjU2IGRvZXMgbm90 IHNob3cgdXAgaW4NCiAgICAgICAgICAgICAgIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIGhhc2gg ZnVuY3Rpb24gbGlzdD8NCg0KLSBzZWN0aW9uIDIuMzogc2hvdWxkIHRoZXJlIGJlIGEgcmVnaXN0 cnkgZm9yIERTIGFsZ29yaXRobXM/DQoNCi0gc2VjdGlvbiAyLjQ6IHNob3VsZCAic2hvdWxkIG5v dCIgYmUgIlNIT1VMRCBOT1QiPyAgZG8gd2Ugd2FudCB0byBhZGQNCiAgICAgICAgICAgICAgIHNv bWUgdGV4dCB0byBkZXNjcmliZSBob3cgdG8gaGFuZGxlIGl0IGlmIHRoZXkgZG8/DQoNCiAgICAi VGhlIGF0dHJpYnV0ZXMgdGhhdCBhcmUgYXBwZW5kZWQgdG8gdGhlDQogICAgIFNpZ25lZCBVUkkg c2hvdWxkIG5vdCBoYXZlIHRoZSBzYW1lIG5hbWUgYXMgdGhpcyBhdHRyaWJ1dGUgdG8gYXZvaWQN CiAgICAgZmFpbGluZyBVUkkgU2lnbmluZyB2YWxpZGF0aW9uLiINCg0KICAgICAgICAgICAgICAg bm90ZTogbXkgdm90ZSBpcyBmb3IgbWFraW5nIHBhY2thZ2luZyBtYW5kYXRvcnkuDQoNCi0gc2Vj dGlvbiAzOiBkbyB3ZSB3YW50IHRvIG5vdGUgdGhhdCBhbGxvd2luZyB0aGUgY2hhbmdpbmcgb2Yg dGhlIFVSTA0KICAgICAgICAgICAgIHNjaGVtZSByZXF1aXJlcyB0aGF0IHRoZSBkZWZhdWx0IHBv cnQgaXMgdXNlZCwgb3IgdGhhdA0KICAgICAgICAgICAgIHRoZSBwcm90b2NvbHMgbXVzdCBib3Ro IHJ1biBvbiB0aGUgc2FtZSBub24tc3RhbmRhcmQgcG9ydD8NCg0KICAgICJUaGUgZW50aXJlIFVS SSBleGNlcHQgdGhlICJzY2hlbWUgbmFtZSIgcGFydCBpcyBwcm90ZWN0ZWQNCiAgICAgYnkgdGhl IFVSSSBzaWduYXR1cmUuICBUaGlzIGFsbG93cyB0aGUgVVJJIHNpZ25hdHVyZSB0byBiZSB2YWxp ZGF0ZWQNCiAgICAgY29ycmVjdGx5IGluIHRoZSBjYXNlIHdoZW4gYSBjbGllbnQgcGVyZm9ybXMg YSBmYWxsYmFjayB0byBhbm90aGVyDQogICAgIHNjaGVtZSAoZS5nLiAgSFRUUCkgZm9yIGEgY29u dGVudCByZWZlcmVuY2VkIGJ5IGFuIFVSSSB3aXRoIGENCiAgICAgc3BlY2lmaWMgc2NoZW1lIChl LmcuICBSVFNQKS4iDQoNCi0gc2VjdGlvbiAzOiBpbiBzdGVwcyA5LkEuaCBhbmQgOS5CLmcsICJ3 aXRoIGVzY2FwZSBjaGFyYWN0ZXJzIiB3YXMgYQ0KICAgICAgICAgICAgIGxpdHRsZSBjb25mdXNp bmcgZm9yIG1lLCBjb3VsZCBqdXN0IHJlbW92ZSBpdD8NCg0KICAgICIgICAgICAgICAgIE5vdGU6 IENvbXB1dGF0aW9uDQogICAgICAgICAgICAgICAgaGFwcGVucyBiZWZvcmUgVVJMIGVuY29kaW5n IHdpdGggZXNjYXBlIGNoYXJhY3RlcnMgaXMNCiAgICAgICAgICAgICAgICBwZXJmb3JtZWQgZm9y IHJlc2VydmVkIGNoYXJhY3RlcnMuIg0KDQotIHNlY3Rpb24gMzogaW4gc3RlcCA5LkIuYywgcXVl cnkgc3RyaW5ncyBhcmUgbm90IGFsbG93ZWQgaW4gdGhlIEtJRD8NCiAgICAgICAgICAgICBwcmVz dW1hYmx5LCB0byBwcmV2ZW50IGNvbmZ1c2lvbiB3aXRoIGl0IGJlaW5nIGluIGEgcXVlcnkNCiAg ICAgICAgICAgICBzdHJpbmcsIGdpdmVuIHRoYXQgaXQgaXMgbm90IFVSTCBlbmNvZGVkPyAgc2hv dWxkIHRoYXQgYmUNCiAgICAgICAgICAgICBub3RlZD8NCg0KLSBzZWN0aW9uIDM6IHN0ZXAgMTAg aGFwcGVucyB3aGV0aGVyIHBhY2thZ2luZyBvciBub3Q/ICBpcyB0aGUgZmlyc3QNCiAgICAgICAg ICAgICBzZW50YW5jZSBuZWNlc3Nhcnk/ICBpZiBzbywgd2hhdCBpcyB0aGUgZGlzdGluY3Rpb24/ DQogICAgICAgICAgICAgZG9lcyBpdCBoYXZlIHRvIGRvIHdpdGggdGhlIGxhY2sgb2YgVVJMIGVu Y29kaW5nIHRvIHRoaXMNCiAgICAgICAgICAgICBwb2ludD8gIGlmIHNvLCBzaG91bGQgdGhhdCBi ZSBub3RlZD8NCg0KICAgICIxMC4gIFdoZW4gcGFja2FnaW5nIHRoZSBVUkkgU2lnbmluZyBhdHRy aWJ1dGVzIGlzIG5vdCBuZWNlc3NhcnksIg0KDQogICAgICAgICAgICAgYXMgbm90ZWQgcHJldmlv dXNseSwgbXkgdm90ZSBpcyBmb3IgbWFuZGF0b3J5IHBhY2thZ2luZy4NCg0KLSBzZWN0aW9uIDQ6 IHdlIG1heSB3YW50IHRvIG5vdGUgdGhhdCB0aGlzIHByb2NlZHVyZSBvbmx5IG9jY3VycyBpZg0K ICAgICAgICAgICAgIFVSTCBzaWduaW5nIGlzIGNvbmZpZ3VyZWQgaW4gdGhlIG1ldGFkYXRhLCBv ciBwZXJoYXBzIGFkZA0KICAgICAgICAgICAgIGNoZWNraW5nIHRoZSBtZXRhZGF0YSBhcyBhIGZp cnN0IHN0ZXA/DQoNCi0gc2VjdGlvbiA0OiBzdGVwIDEgdXNlcyB0aGUgbGFzdCBpbnN0YW5jZSBv ZiB0aGUgcGFja2FnaW5nIGF0dHJpYnV0ZS4NCiAgICAgICAgICAgICB0aGlzIGFsbG93cyBmb3Ig YSBzaW1wbGUgRG9TIGF0dGFjayB3aGVyZWJ5IGEgYm9ndXMNCiAgICAgICAgICAgICBwYWNrYWdp bmcgYXR0cmlidXRlIGNhbiBiZSBhcHBlbmRlZCB3aXRob3V0IG5lZWRpbmcgdG8NCiAgICAgICAg ICAgICBrbm93IGFueXRoaW5nIGFib3V0IHRoZSBzaWduaW5nIGNvbmZpZ3VyYXRpb24/ICBub3Rl Og0KICAgICAgICAgICAgIHRoaXMgY29tbWVudCBhcHBsaWVzIGluIGdlbmVyYWwgdG8gc3RlcHMg NCBhbmQgNSBhcyB3ZWxsLA0KICAgICAgICAgICAgIHdoZXJlIHRoZSB0aW1lIHdpbmRvdyBhbmQg Y2xpZW50IElQIGFyZSBub3QgYXNzb2NpYXRlZA0KICAgICAgICAgICAgIHdpdGggYSB2YWxpZCBz aWduYXR1cmUgcHJpb3IgdG8gZW5mb3JjZW1lbnQuDQoNCiAgICAiICAgICAgSWYgdGhlcmUgYXJl IG11bHRpcGxlDQogICAgICAgICAgIGluc3RhbmNlcyBvZiB0aGlzIGF0dHJpYnV0ZSwgdGhlIGxh c3Qgb25lIGlzIHVzZWQuIg0KDQogICAgICAgICAgICAgYW4gYWx0ZXJuYXRpdmUgd291bGQgYmUg dG8gdHJ5IHRoZW0gYWxsPw0KDQotIHNlY3Rpb24gNDogc3RlcCAzIGFsbG93cyBWRVIgdG8gYmUg c3BlY2lmaWVkIGluIGEgImNvbmZpZ3VyYXRpb24iLA0KICAgICAgICAgICAgIGhvd2V2ZXIgdGhp cyBzZWVtcyB0byBjb250cmFkaWN0IHNlY3Rpb24gMi4yIHdoaWNoIHN0YXRlcw0KICAgICAgICAg ICAgIHRoYXQgdGhlIHZlcnNpb24gZGVmYXVsdHMgdG8gMSwgdW5sZXNzIHNwZWNpZmllZCBpbiB0 aGUNCiAgICAgICAgICAgICBtZXRhZGF0YS4gIG5vdGU6IHRoaXMgY29tbWVudCBhcHBsaWVzIGlu IGdlbmVyYWwgdG8gc3RlcHMNCiAgICAgICAgICAgICA0LkEuYSwgNC5BLmIsIGFuZCA0LkIuYSBh cyB3ZWxsLg0KDQogICAgIiAgICAgIGUuZy4gY29uZmlndXJhdGlvbg0KICAgICAgICAgICBvciBD RE5JIG1ldGFkYXRhKS4iDQoNCi0gc2VjdGlvbiA0OiBzdGVwcyA0LkEuZiBhbmQgNC5CLmUsIFVS TCBkZWNvZGluZyBzaG91bGQgaGF2ZSBvY2N1cnJlZA0KICAgICAgICAgICAgIGJlZm9yZSBhbnkg b2YgdGhlIHByb2Nlc3NlcyBpbiBzZWN0aW9uIDQgb2NjdXI/ICBzaG91bGQNCiAgICAgICAgICAg ICB0aGF0IGp1c3QgYmUgbm90ZWQgdXAgZnJvbnQ/ICBhbHNvLCBzaW1pbGFyIHRvIHRoZQ0KICAg ICAgICAgICAgIHByZXZpb3VzIGNvbW1lbnQsIGZvciBjbGFyaXR5LCBjb3VsZCBqdXN0IHJlbW92 ZSAiZm9yDQogICAgICAgICAgICAgcmVzZXJ2ZWQgY2hhcmFjdGVycyI/IA0KDQogICAgIiAgICAg IE5vdGU6DQogICAgICAgICAgIENvbXB1dGF0aW9uIGhhcHBlbnMgYWZ0ZXIgVVJMIGRlY29kaW5n IG9mIHRoZSBlc2NhcGUNCiAgICAgICAgICAgY2hhcmFjdGVycyBpcyBwZXJmb3JtZWQgZm9yIHJl c2VydmVkIGNoYXJhY3RlcnMuIg0KDQotIHNlY3Rpb24gNDogdGhlIHByb2Nlc3MgcHJvdmlkZWQg YXNzdW1lcyBwYWNrYWdpbmc/ICBpZiB0aGVyZSBpcyBubw0KICAgICAgICAgICAgIHBhY2thZ2lu ZyB3ZSBtYXkgbmVlZCB0byBzcGVjaWZ5IGFkZGl0aW9uYWwgcnVsZXMgZm9yDQogICAgICAgICAg ICAgc2VsZWN0aW5nIHdoaWNoIGF0dHJpYnV0ZXMgdG8gdXNlLCBpZiB0aGVyZSBhcmUgZHVwbGlj YXRlcz8NCg0KICAgICAgICAgICAgIGFzIG5vdGVkIGFib3ZlLCBteSBwcmVmZXJlbmNlIHdvdWxk IGJlIHRvIG1ha2UgcGFja2FnaW5nDQogICAgICAgICAgICAgbWFuZGF0b3J5LCB0byBhdm9pZCB0 aGVzZSBpc3N1ZXMuDQoNCi0gc2VjdGlvbiA1LjQ6IHRoaXMgc2VudGFuY2Ugd2FzIGNvbmZ1c2lu ZyB0byBtZSBhdCBmaXJzdC4NCiAgICAgICAgICAgICAgIGVzc2VudGlhbGx5IGFueW9uZSBjYW4g Y3JlYXRlIGEgcHVibGljL3ByaXZhdGUga2V5IHBhaXIsDQogICAgICAgICAgICAgICBwdXQgdGhl IHB1YmxpYyBpbiB0aGUgVVJMIGFuZCBzaWduIHdpdGggdGhlIHByaXZhdGUsIHNvDQogICAgICAg ICAgICAgICB3ZSBuZWVkIHRvIHZlcmlmeSB0aGUgcHVibGljIGtleT8gIHNvIHRoZW4sIHdoeSBh bGxvdw0KICAgICAgICAgICAgICAgdGhlIGtleSBpZCB0byBiZSBhIFVSTCBhdCBhbGw/ICBqdXN0 IG1ha2UgaXQgYSBrZXkgaWQNCiAgICAgICAgICAgICAgIChpdCBpZiBoYXBwZW5kcyB0byBiZSBh IFVSTCwgZmluZSwgYnV0IGRvIG5vdCBhbGxvdyBpdA0KICAgICAgICAgICAgICAgdG8gYmUgaW50 ZXJwcmV0ZWQgYXMgYSBVUkwpLCBhbmQgb25seSBhbGxvdyB0aGUgYWN0dWFsDQogICAgICAgICAg ICAgICBVUkwgdG8gYmUgc3BlY2lmaWVkIGluIG1ldGFkYXRhPw0KDQogICAgInRoZSBDRE5JIE1l dGFkYXRhIEludGVyZmFjZSBNVVNUIHByb3ZpZGUgdGhlIHB1YmxpYyBrZXkgZm9yIHRoZQ0KICAg ICBjb250ZW50IG9yIGluZm9ybWF0aW9uIHRvIGF1dGhvcml6ZSB0aGUgcmVjZWl2ZWQgS2V5IElE IGF0dHJpYnV0ZS4NCg0KLSBzZWN0aW9uIDk6IHNob3VsZCBzaWduYXR1cmUgdmFsaWRhdGlvbiBv Y2N1ciBiZWZvcmUgSFRUUCBwcm9jZXNzaW5nLA0KICAgICAgICAgICAgIGUuZy4sIGlmLW1vZGlm aWVkLXNpbmNlIGhlYWRlcnM/DQoNCi0gc2VjdGlvbiA5OiB0aGVyZSBhcmUgc29tZSBvYnZpb3Vz IGNvbXBsZXhpdGllcyB0byB0aGlzLCBhbmQgdGhlDQogICAgICAgICAgICAgaXNzdWUgb2YgcmVq ZWN0aW5nIGxlZ2l0aW1hdGUgcmUtcmVxdWVzdHM/ICBJcyB0aGUgaW50ZW50DQogICAgICAgICAg ICAgdG8gb2ZmZXIgYWx0ZXJuYXRpdmVzIGZvciBiZXR0ZXIgc2VjdXJpdHksIG9yIGp1c3QgdG8N CiAgICAgICAgICAgICBkb2N1bWVudCBrbm93biBzZWN1cml0eSBpc3N1ZXM/DQoNCiAgICAiICAg T25lIHdheSB0byByZWR1Y2UgZXhwb3N1cmUgdG8gcmVwbGF5DQogICAgICAgIGF0dGFja3MgaXMg dG8gaW5jbHVkZSBpbiB0aGUgVVJJIGEgdW5pcXVlIG9uZS10aW1lIGFjY2VzcyBJRC4iDQoNCiAg ICAgICAgICAgICBzaW1pbGFyIGNvbW1lbnQgaGVyZToNCg0KICAgICIgICBPbmUgd2F5IHRvDQog ICAgICAgIHJlZHVjZSBleHBvc3VyZSB0byB0aGlzIGtpbmQgb2YgYXR0YWNrIGlzIHRvIG5vdCBv bmx5IGNoZWNrIGZvcg0KICAgICAgICBDbGllbnQgSVAgYnV0IGFsc28gZm9yIG90aGVyIGF0dHJp YnV0ZXMgdGhhdCBjYW4gYmUgZm91bmQgaW4gdGhlDQogICAgICAgIEhUVFAgaGVhZGVycy4iDQoN Cm5pdHM6DQoNCi0gYWJzdHJhY3Q6ICJyZXF1ZXN0IiAtPiAicmVxdWVzdHMiDQoNCi0gc2VjdGlv biAxLjM6ICJDU1AgbWF5IGNob29zZSIgLT4gInRoZSBDU1AgbWF5IGNob29zZSINCg0KLSBzZWN0 aW9uIDIuNDogIndob20iIC0+ICJ3aG8iPw0KDQotIHNlY3Rpb24gMi40OiAiU0lnbmluZyIgLT4g IlNpZ25pbmciDQoNCi0gc2VjdGlvbiAyLjQ6ICJ0aGVCYXNlLTY0IiAtPiAidGhlIEJhc2UtNjQi DQoNCi0gc2VjdGlvbiAzOiBpbiBzdGVwIDkuQi5pOiAiZGVub3RlZCIgLT4gImRlbGltaXRlZCI/ DQoNCi0gc2VjdGlvbiA0OiBzdGVwIDI6ICJtZXRhZGEiIC0+ICJtZXRhZGF0YSINCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBLZW50IExldW5nIChr bGV1bmcpDQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTMgMToyNCBBTQ0KPiBU bzogY2RuaUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbQ0ROaV0gRlc6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbGV1bmctY2RuaS11cmktDQo+IHNpZ25pbmctMDMudHh0DQo+IA0K PiBIaSBmb2xrcy4gQmFzZWQgb24gdGhlIGRpc2N1c3Npb25zIGF0IHRoZSBsYXN0IElFVEYgbWVl dGluZywgSeKAmXZlIG1hZGUgdGhlDQo+IHVwZGF0ZXMgdG8gdGhlIGRyYWZ0LiBTb21lIG9mIHRo ZSBrZXkgY2hhbmdlcyB3ZXJlOg0KPiANCj4gLSBVcGRhdGVkIFVSSSBTaWduaW5nIGluIGEgQ0RO SSBFbnZpcm9ubWVudCBmaWd1cmUNCj4gLSBTcGVjaWZpZWQgdGhhdCBhdHRyaWJ1dGVzIGFkZGVk IGJ5IFVBL290aGVyICBlbnRpdHkgbmVlZCB0byBiZSBhZnRlciB0aGUNCj4gQ0ROSSBVUkkgU2ln bmluZyBhdHRyaWJ1dGUNCj4gLSBVUkkgU2lnbmluZyBUb2tlbiBhdHRyaWJ1dGUgcmVuYW1lZCB0 byBVUkkgU2lnbmluZyBQYWNrYWdlIGF0dHJpYnV0ZSwNCj4gd2hpY2ggaXMgbm93IG1hbmRhdG9y eQ0KPiANCj4gUmV2aWV3IGNvbW1lbnRzIGFyZSB3ZWxjb21lLiBUaGFua3MuDQo+IA0KPiBLZW50 DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IEZy aWRheSwgQXVndXN0IDMwLCAyMDEzIDEyOjMxIFBNDQo+IFRvOiBSYXkgdmFuIEJyYW5kZW5idXJn OyBTY290dCBMZWlicmFuZDsgS2VudCBMZXVuZyAoa2xldW5nKTsgRnJhbmNvaXMgTGUNCj4gRmF1 Y2hldXIgKGZsZWZhdWNoKTsgQmlsbCBEb3duZXkNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1sZXVuZy1jZG5pLXVyaS1zaWduaW5nLTAzLnR4dA0KPiANCj4g DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1sZXVuZy1jZG5pLXVyaS1zaWduaW5nLTAz LnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEtlbnQgTGV1bmcgYW5k IHBvc3RlZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6CSBkcmFm dC1sZXVuZy1jZG5pLXVyaS1zaWduaW5nDQo+IFJldmlzaW9uOgkgMDMNCj4gVGl0bGU6CQkgVVJJ IFNpZ25pbmcgZm9yIENETiBJbnRlcmNvbm5lY3Rpb24gKENETkkpDQo+IENyZWF0aW9uIGRhdGU6 CSAyMDEzLTA4LTMwDQo+IEdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIg b2YgcGFnZXM6IDMzDQo+IFVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtbGV1bmctY2RuaS11cmktDQo+IHNpZ25pbmctMDMudHh0DQo+IFN0 YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sZXVu Zy1jZG5pLXVyaS0NCj4gc2lnbmluZw0KPiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWxldW5nLWNkbmktdXJpLXNpZ25pbmctDQo+IDAzDQo+IERpZmY6 ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGV1bmct Y2RuaS11cmktDQo+IHNpZ25pbmctMDMNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBob3cgdGhlIGNvbmNlcHQgb2YgVVJJIHNpZ25pbmcgc3VwcG9ydHMgdGhl DQo+ICAgIGNvbnRlbnQgYWNjZXNzIGNvbnRyb2wgcmVxdWlyZW1lbnRzIG9mIENETkkgYW5kIHBy b3Bvc2VzIGEgY2FuZGlkYXRlDQo+ICAgIFVSSSBzaWduaW5nIHNjaGVtZS4NCj4gDQo+ICAgIFRo ZSBwcm9wb3NlZCBVUkkgc2lnbmluZyBtZXRob2Qgc3BlY2lmaWVzIHRoZSBpbmZvcm1hdGlvbiBu ZWVkZWQgdG8NCj4gICAgYmUgaW5jbHVkZWQgaW4gdGhlIFVSSSBhbmQgdGhlIGFsZ29yaXRobSB1 c2VkIHRvIGF1dGhvcml6ZSBhbmQgdG8NCj4gICAgdmFsaWRhdGUgYWNjZXNzIHJlcXVlc3QgZm9y IHRoZSBjb250ZW50IHJlZmVyZW5jZWQgYnkgdGhlIFVSSS4gIFNvbWUNCj4gICAgb2YgdGhlIGlu Zm9ybWF0aW9uIG1heSBiZSBhY2Nlc3NlZCBieSB0aGUgQ0ROIHZpYSBjb25maWd1cmF0aW9uIG9y DQo+ICAgIENETkkgbWV0YWRhdGEuDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQNCj4gdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0ROaSBt YWlsaW5nIGxpc3QNCj4gQ0ROaUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NkbmkNCg== From internet-drafts@ietf.org Mon Nov 4 11:01:22 2013 Return-Path: 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 0244511E821D; Mon, 4 Nov 2013 11:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IWHrGo8UJW8; Mon, 4 Nov 2013 11:01:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDCE11E81EA; Mon, 4 Nov 2013 11:01:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131104190118.10133.46872.idtracker@ietfa.amsl.com> Date: Mon, 04 Nov 2013 11:01:18 -0800 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-12.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:01:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Requ= irements Author(s) : Kent Leung Yiu Lee Filename : draft-ietf-cdni-requirements-12.txt Pages : 24 Date : 2013-11-04 Abstract: Content Delivery Networks (CDNs) are frequently used for content delivery. As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers and Enterprise Service Providers are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-requirements-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kleung@cisco.com Mon Nov 4 11:07:11 2013 Return-Path: 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 C388421E80FA for ; Mon, 4 Nov 2013 11:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlaHvtPe5xct for ; Mon, 4 Nov 2013 11:07:06 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 53D5911E812B for ; Mon, 4 Nov 2013 11:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12954; q=dns/txt; s=iport; t=1383592026; x=1384801626; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WafbDHgr0uxY3ksfGmxk/YTHriKM8od3smQQEndf7GQ=; b=OM9nG1xyMisoRZR/PjT31ldn6EPpoOiZyH+pY+Iuu+ChrrHGbmXA1F+h BR9XZSc2aD9/6D0zlVuf5PToswSb61qwNBaWm/RFfl4OfzPkffokPHdYG V4vo+MNGzcZvZjIvvVnzPfCtKiT2Z+LDCrXlLF88R7+55qquuYFf+LZfV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUGADLvd1KtJV2Y/2dsb2JhbABZgwc4TQaDCLw3GIETFnSCJQEBAQQBAQEgBA06CQ4EAgEIEQQBAQMCBh0DAgICJQsUAQcBCAIEARIIAYd4CAWsFJI5gSmNfhYiBoJlNYEOA5k5kFqDJoFqJBw X-IronPort-AV: E=Sophos;i="4.93,634,1378857600"; d="scan'208";a="280592700" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 04 Nov 2013 19:07:05 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA4J751g001090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 19:07:05 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 13:07:05 -0600 From: "Kent Leung (kleung)" To: Kevin J Ma , "cdni@ietf.org" Thread-Topic: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-03.txt Thread-Index: AQHO2ZEM+QaGIUG1GkiGxLwCJJsheA== Date: Mon, 4 Nov 2013 19:07:04 +0000 Message-ID: References: <20130830193036.1149.11538.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6B027F59C2C@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B027F59C2C@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.67.253] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-03.txt 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 19:07:11 -0000 SGkgS2V2aW4uIFRoYW5rcyBmb3IgeW91ciB0aG9yb3VnaCByZXZpZXcuIExldCBtZSBzcGVuZCBz b21lIHRpbWUgb24geW91ciBjb21tZW50cyBhbmQgcmVzcG9uZCBsYXRlci4NCg0KS2VudA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2V2aW4gSiBNYSBbbWFpbHRvOmtldmlu Lm1hQGF6dWtpc3lzdGVtcy5jb21dIA0KU2VudDogU3VuZGF5LCBOb3ZlbWJlciAwMywgMjAxMyA4 OjE0IFBNDQpUbzogS2VudCBMZXVuZyAoa2xldW5nKTsgY2RuaUBpZXRmLm9yZw0KU3ViamVjdDog UkU6IFtDRE5pXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1sZXVuZy1j ZG5pLXVyaS1zaWduaW5nLTAzLnR4dA0KDQpIaSBLZW50LA0KDQogIFRoZSB1cGRhdGVzIHNpbmNl IEJlcmxpbiBsb29rIGdvb2QuDQoNCj4gLSBVUkkgU2lnbmluZyBUb2tlbiBhdHRyaWJ1dGUgcmVu YW1lZCB0byBVUkkgU2lnbmluZyBQYWNrYWdlIA0KPiBhdHRyaWJ1dGUsIHdoaWNoIGlzIG5vdyBt YW5kYXRvcnkNCg0KICBTb21lIHBhcnRzIG9mIHRoZSBkcmFmdCBzdGlsbCByZWFkIGFzIHRob3Vn aHQgcGFja2FnaW5nIGlzIG9wdGlvbmFsPw0KDQogIENvbW1lbnRzL3F1ZXN0aW9ucyBvbiB0aGUg bGF0ZXN0IGRyYWZ0IGJlbG93Lg0KDQp0aGFueC4NCg0KLS0gIEtldmluIEouIE1hDQoNCmNvbW1l bnRzOg0KDQotIHNlY3Rpb24gMS4zOiBzaG91bGQgIm5lZWRzIiBiZSBhIFNIT1VMRCBvciBhIE1V U1Q/DQoNCiAgICAiTm90ZSB0aGF0IHRoZSBzaWduZWQgUmVkaXJlY3Rpb24gVVJJDQogICAgIG5l ZWRzIHRvIG1haW50YWluIHRoZSBzYW1lIGxldmVsIG9mIHNlY3VyaXR5IGFzIHRoZSBvcmlnaW5h bCBTaWduZWQNCiAgICAgVVJJLiINCg0KLSBzZWN0aW9uIDIuMTogZG8gd2Ugd2FudCB0byByZWZl cmVuY2UgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQogICAgICAgICAgICAgICBzZWN0aW9u IHdydCBFVC9DSVAgbGltaXRhdGlvbnM/DQoNCi0gc2VjdGlvbiAyLjI6IHRoZSBkZWZhdWx0IGhh c2ggZnVuY3Rpb24gU0hBMjU2IGRvZXMgbm90IHNob3cgdXAgaW4NCiAgICAgICAgICAgICAgIHRo ZSBJQU5BIGNvbnNpZGVyYXRpb25zIGhhc2ggZnVuY3Rpb24gbGlzdD8NCg0KLSBzZWN0aW9uIDIu Mzogc2hvdWxkIHRoZXJlIGJlIGEgcmVnaXN0cnkgZm9yIERTIGFsZ29yaXRobXM/DQoNCi0gc2Vj dGlvbiAyLjQ6IHNob3VsZCAic2hvdWxkIG5vdCIgYmUgIlNIT1VMRCBOT1QiPyAgZG8gd2Ugd2Fu dCB0byBhZGQNCiAgICAgICAgICAgICAgIHNvbWUgdGV4dCB0byBkZXNjcmliZSBob3cgdG8gaGFu ZGxlIGl0IGlmIHRoZXkgZG8/DQoNCiAgICAiVGhlIGF0dHJpYnV0ZXMgdGhhdCBhcmUgYXBwZW5k ZWQgdG8gdGhlDQogICAgIFNpZ25lZCBVUkkgc2hvdWxkIG5vdCBoYXZlIHRoZSBzYW1lIG5hbWUg YXMgdGhpcyBhdHRyaWJ1dGUgdG8gYXZvaWQNCiAgICAgZmFpbGluZyBVUkkgU2lnbmluZyB2YWxp ZGF0aW9uLiINCg0KICAgICAgICAgICAgICAgbm90ZTogbXkgdm90ZSBpcyBmb3IgbWFraW5nIHBh Y2thZ2luZyBtYW5kYXRvcnkuDQoNCi0gc2VjdGlvbiAzOiBkbyB3ZSB3YW50IHRvIG5vdGUgdGhh dCBhbGxvd2luZyB0aGUgY2hhbmdpbmcgb2YgdGhlIFVSTA0KICAgICAgICAgICAgIHNjaGVtZSBy ZXF1aXJlcyB0aGF0IHRoZSBkZWZhdWx0IHBvcnQgaXMgdXNlZCwgb3IgdGhhdA0KICAgICAgICAg ICAgIHRoZSBwcm90b2NvbHMgbXVzdCBib3RoIHJ1biBvbiB0aGUgc2FtZSBub24tc3RhbmRhcmQg cG9ydD8NCg0KICAgICJUaGUgZW50aXJlIFVSSSBleGNlcHQgdGhlICJzY2hlbWUgbmFtZSIgcGFy dCBpcyBwcm90ZWN0ZWQNCiAgICAgYnkgdGhlIFVSSSBzaWduYXR1cmUuICBUaGlzIGFsbG93cyB0 aGUgVVJJIHNpZ25hdHVyZSB0byBiZSB2YWxpZGF0ZWQNCiAgICAgY29ycmVjdGx5IGluIHRoZSBj YXNlIHdoZW4gYSBjbGllbnQgcGVyZm9ybXMgYSBmYWxsYmFjayB0byBhbm90aGVyDQogICAgIHNj aGVtZSAoZS5nLiAgSFRUUCkgZm9yIGEgY29udGVudCByZWZlcmVuY2VkIGJ5IGFuIFVSSSB3aXRo IGENCiAgICAgc3BlY2lmaWMgc2NoZW1lIChlLmcuICBSVFNQKS4iDQoNCi0gc2VjdGlvbiAzOiBp biBzdGVwcyA5LkEuaCBhbmQgOS5CLmcsICJ3aXRoIGVzY2FwZSBjaGFyYWN0ZXJzIiB3YXMgYQ0K ICAgICAgICAgICAgIGxpdHRsZSBjb25mdXNpbmcgZm9yIG1lLCBjb3VsZCBqdXN0IHJlbW92ZSBp dD8NCg0KICAgICIgICAgICAgICAgIE5vdGU6IENvbXB1dGF0aW9uDQogICAgICAgICAgICAgICAg aGFwcGVucyBiZWZvcmUgVVJMIGVuY29kaW5nIHdpdGggZXNjYXBlIGNoYXJhY3RlcnMgaXMNCiAg ICAgICAgICAgICAgICBwZXJmb3JtZWQgZm9yIHJlc2VydmVkIGNoYXJhY3RlcnMuIg0KDQotIHNl Y3Rpb24gMzogaW4gc3RlcCA5LkIuYywgcXVlcnkgc3RyaW5ncyBhcmUgbm90IGFsbG93ZWQgaW4g dGhlIEtJRD8NCiAgICAgICAgICAgICBwcmVzdW1hYmx5LCB0byBwcmV2ZW50IGNvbmZ1c2lvbiB3 aXRoIGl0IGJlaW5nIGluIGEgcXVlcnkNCiAgICAgICAgICAgICBzdHJpbmcsIGdpdmVuIHRoYXQg aXQgaXMgbm90IFVSTCBlbmNvZGVkPyAgc2hvdWxkIHRoYXQgYmUNCiAgICAgICAgICAgICBub3Rl ZD8NCg0KLSBzZWN0aW9uIDM6IHN0ZXAgMTAgaGFwcGVucyB3aGV0aGVyIHBhY2thZ2luZyBvciBu b3Q/ICBpcyB0aGUgZmlyc3QNCiAgICAgICAgICAgICBzZW50YW5jZSBuZWNlc3Nhcnk/ICBpZiBz bywgd2hhdCBpcyB0aGUgZGlzdGluY3Rpb24/DQogICAgICAgICAgICAgZG9lcyBpdCBoYXZlIHRv IGRvIHdpdGggdGhlIGxhY2sgb2YgVVJMIGVuY29kaW5nIHRvIHRoaXMNCiAgICAgICAgICAgICBw b2ludD8gIGlmIHNvLCBzaG91bGQgdGhhdCBiZSBub3RlZD8NCg0KICAgICIxMC4gIFdoZW4gcGFj a2FnaW5nIHRoZSBVUkkgU2lnbmluZyBhdHRyaWJ1dGVzIGlzIG5vdCBuZWNlc3NhcnksIg0KDQog ICAgICAgICAgICAgYXMgbm90ZWQgcHJldmlvdXNseSwgbXkgdm90ZSBpcyBmb3IgbWFuZGF0b3J5 IHBhY2thZ2luZy4NCg0KLSBzZWN0aW9uIDQ6IHdlIG1heSB3YW50IHRvIG5vdGUgdGhhdCB0aGlz IHByb2NlZHVyZSBvbmx5IG9jY3VycyBpZg0KICAgICAgICAgICAgIFVSTCBzaWduaW5nIGlzIGNv bmZpZ3VyZWQgaW4gdGhlIG1ldGFkYXRhLCBvciBwZXJoYXBzIGFkZA0KICAgICAgICAgICAgIGNo ZWNraW5nIHRoZSBtZXRhZGF0YSBhcyBhIGZpcnN0IHN0ZXA/DQoNCi0gc2VjdGlvbiA0OiBzdGVw IDEgdXNlcyB0aGUgbGFzdCBpbnN0YW5jZSBvZiB0aGUgcGFja2FnaW5nIGF0dHJpYnV0ZS4NCiAg ICAgICAgICAgICB0aGlzIGFsbG93cyBmb3IgYSBzaW1wbGUgRG9TIGF0dGFjayB3aGVyZWJ5IGEg Ym9ndXMNCiAgICAgICAgICAgICBwYWNrYWdpbmcgYXR0cmlidXRlIGNhbiBiZSBhcHBlbmRlZCB3 aXRob3V0IG5lZWRpbmcgdG8NCiAgICAgICAgICAgICBrbm93IGFueXRoaW5nIGFib3V0IHRoZSBz aWduaW5nIGNvbmZpZ3VyYXRpb24/ICBub3RlOg0KICAgICAgICAgICAgIHRoaXMgY29tbWVudCBh cHBsaWVzIGluIGdlbmVyYWwgdG8gc3RlcHMgNCBhbmQgNSBhcyB3ZWxsLA0KICAgICAgICAgICAg IHdoZXJlIHRoZSB0aW1lIHdpbmRvdyBhbmQgY2xpZW50IElQIGFyZSBub3QgYXNzb2NpYXRlZA0K ICAgICAgICAgICAgIHdpdGggYSB2YWxpZCBzaWduYXR1cmUgcHJpb3IgdG8gZW5mb3JjZW1lbnQu DQoNCiAgICAiICAgICAgSWYgdGhlcmUgYXJlIG11bHRpcGxlDQogICAgICAgICAgIGluc3RhbmNl cyBvZiB0aGlzIGF0dHJpYnV0ZSwgdGhlIGxhc3Qgb25lIGlzIHVzZWQuIg0KDQogICAgICAgICAg ICAgYW4gYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gdHJ5IHRoZW0gYWxsPw0KDQotIHNlY3Rpb24g NDogc3RlcCAzIGFsbG93cyBWRVIgdG8gYmUgc3BlY2lmaWVkIGluIGEgImNvbmZpZ3VyYXRpb24i LA0KICAgICAgICAgICAgIGhvd2V2ZXIgdGhpcyBzZWVtcyB0byBjb250cmFkaWN0IHNlY3Rpb24g Mi4yIHdoaWNoIHN0YXRlcw0KICAgICAgICAgICAgIHRoYXQgdGhlIHZlcnNpb24gZGVmYXVsdHMg dG8gMSwgdW5sZXNzIHNwZWNpZmllZCBpbiB0aGUNCiAgICAgICAgICAgICBtZXRhZGF0YS4gIG5v dGU6IHRoaXMgY29tbWVudCBhcHBsaWVzIGluIGdlbmVyYWwgdG8gc3RlcHMNCiAgICAgICAgICAg ICA0LkEuYSwgNC5BLmIsIGFuZCA0LkIuYSBhcyB3ZWxsLg0KDQogICAgIiAgICAgIGUuZy4gY29u ZmlndXJhdGlvbg0KICAgICAgICAgICBvciBDRE5JIG1ldGFkYXRhKS4iDQoNCi0gc2VjdGlvbiA0 OiBzdGVwcyA0LkEuZiBhbmQgNC5CLmUsIFVSTCBkZWNvZGluZyBzaG91bGQgaGF2ZSBvY2N1cnJl ZA0KICAgICAgICAgICAgIGJlZm9yZSBhbnkgb2YgdGhlIHByb2Nlc3NlcyBpbiBzZWN0aW9uIDQg b2NjdXI/ICBzaG91bGQNCiAgICAgICAgICAgICB0aGF0IGp1c3QgYmUgbm90ZWQgdXAgZnJvbnQ/ ICBhbHNvLCBzaW1pbGFyIHRvIHRoZQ0KICAgICAgICAgICAgIHByZXZpb3VzIGNvbW1lbnQsIGZv ciBjbGFyaXR5LCBjb3VsZCBqdXN0IHJlbW92ZSAiZm9yDQogICAgICAgICAgICAgcmVzZXJ2ZWQg Y2hhcmFjdGVycyI/IA0KDQogICAgIiAgICAgIE5vdGU6DQogICAgICAgICAgIENvbXB1dGF0aW9u IGhhcHBlbnMgYWZ0ZXIgVVJMIGRlY29kaW5nIG9mIHRoZSBlc2NhcGUNCiAgICAgICAgICAgY2hh cmFjdGVycyBpcyBwZXJmb3JtZWQgZm9yIHJlc2VydmVkIGNoYXJhY3RlcnMuIg0KDQotIHNlY3Rp b24gNDogdGhlIHByb2Nlc3MgcHJvdmlkZWQgYXNzdW1lcyBwYWNrYWdpbmc/ICBpZiB0aGVyZSBp cyBubw0KICAgICAgICAgICAgIHBhY2thZ2luZyB3ZSBtYXkgbmVlZCB0byBzcGVjaWZ5IGFkZGl0 aW9uYWwgcnVsZXMgZm9yDQogICAgICAgICAgICAgc2VsZWN0aW5nIHdoaWNoIGF0dHJpYnV0ZXMg dG8gdXNlLCBpZiB0aGVyZSBhcmUgZHVwbGljYXRlcz8NCg0KICAgICAgICAgICAgIGFzIG5vdGVk IGFib3ZlLCBteSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIG1ha2UgcGFja2FnaW5nDQogICAgICAg ICAgICAgbWFuZGF0b3J5LCB0byBhdm9pZCB0aGVzZSBpc3N1ZXMuDQoNCi0gc2VjdGlvbiA1LjQ6 IHRoaXMgc2VudGFuY2Ugd2FzIGNvbmZ1c2luZyB0byBtZSBhdCBmaXJzdC4NCiAgICAgICAgICAg ICAgIGVzc2VudGlhbGx5IGFueW9uZSBjYW4gY3JlYXRlIGEgcHVibGljL3ByaXZhdGUga2V5IHBh aXIsDQogICAgICAgICAgICAgICBwdXQgdGhlIHB1YmxpYyBpbiB0aGUgVVJMIGFuZCBzaWduIHdp dGggdGhlIHByaXZhdGUsIHNvDQogICAgICAgICAgICAgICB3ZSBuZWVkIHRvIHZlcmlmeSB0aGUg cHVibGljIGtleT8gIHNvIHRoZW4sIHdoeSBhbGxvdw0KICAgICAgICAgICAgICAgdGhlIGtleSBp ZCB0byBiZSBhIFVSTCBhdCBhbGw/ICBqdXN0IG1ha2UgaXQgYSBrZXkgaWQNCiAgICAgICAgICAg ICAgIChpdCBpZiBoYXBwZW5kcyB0byBiZSBhIFVSTCwgZmluZSwgYnV0IGRvIG5vdCBhbGxvdyBp dA0KICAgICAgICAgICAgICAgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgYSBVUkwpLCBhbmQgb25seSBh bGxvdyB0aGUgYWN0dWFsDQogICAgICAgICAgICAgICBVUkwgdG8gYmUgc3BlY2lmaWVkIGluIG1l dGFkYXRhPw0KDQogICAgInRoZSBDRE5JIE1ldGFkYXRhIEludGVyZmFjZSBNVVNUIHByb3ZpZGUg dGhlIHB1YmxpYyBrZXkgZm9yIHRoZQ0KICAgICBjb250ZW50IG9yIGluZm9ybWF0aW9uIHRvIGF1 dGhvcml6ZSB0aGUgcmVjZWl2ZWQgS2V5IElEIGF0dHJpYnV0ZS4NCg0KLSBzZWN0aW9uIDk6IHNo b3VsZCBzaWduYXR1cmUgdmFsaWRhdGlvbiBvY2N1ciBiZWZvcmUgSFRUUCBwcm9jZXNzaW5nLA0K ICAgICAgICAgICAgIGUuZy4sIGlmLW1vZGlmaWVkLXNpbmNlIGhlYWRlcnM/DQoNCi0gc2VjdGlv biA5OiB0aGVyZSBhcmUgc29tZSBvYnZpb3VzIGNvbXBsZXhpdGllcyB0byB0aGlzLCBhbmQgdGhl DQogICAgICAgICAgICAgaXNzdWUgb2YgcmVqZWN0aW5nIGxlZ2l0aW1hdGUgcmUtcmVxdWVzdHM/ ICBJcyB0aGUgaW50ZW50DQogICAgICAgICAgICAgdG8gb2ZmZXIgYWx0ZXJuYXRpdmVzIGZvciBi ZXR0ZXIgc2VjdXJpdHksIG9yIGp1c3QgdG8NCiAgICAgICAgICAgICBkb2N1bWVudCBrbm93biBz ZWN1cml0eSBpc3N1ZXM/DQoNCiAgICAiICAgT25lIHdheSB0byByZWR1Y2UgZXhwb3N1cmUgdG8g cmVwbGF5DQogICAgICAgIGF0dGFja3MgaXMgdG8gaW5jbHVkZSBpbiB0aGUgVVJJIGEgdW5pcXVl IG9uZS10aW1lIGFjY2VzcyBJRC4iDQoNCiAgICAgICAgICAgICBzaW1pbGFyIGNvbW1lbnQgaGVy ZToNCg0KICAgICIgICBPbmUgd2F5IHRvDQogICAgICAgIHJlZHVjZSBleHBvc3VyZSB0byB0aGlz IGtpbmQgb2YgYXR0YWNrIGlzIHRvIG5vdCBvbmx5IGNoZWNrIGZvcg0KICAgICAgICBDbGllbnQg SVAgYnV0IGFsc28gZm9yIG90aGVyIGF0dHJpYnV0ZXMgdGhhdCBjYW4gYmUgZm91bmQgaW4gdGhl DQogICAgICAgIEhUVFAgaGVhZGVycy4iDQoNCm5pdHM6DQoNCi0gYWJzdHJhY3Q6ICJyZXF1ZXN0 IiAtPiAicmVxdWVzdHMiDQoNCi0gc2VjdGlvbiAxLjM6ICJDU1AgbWF5IGNob29zZSIgLT4gInRo ZSBDU1AgbWF5IGNob29zZSINCg0KLSBzZWN0aW9uIDIuNDogIndob20iIC0+ICJ3aG8iPw0KDQot IHNlY3Rpb24gMi40OiAiU0lnbmluZyIgLT4gIlNpZ25pbmciDQoNCi0gc2VjdGlvbiAyLjQ6ICJ0 aGVCYXNlLTY0IiAtPiAidGhlIEJhc2UtNjQiDQoNCi0gc2VjdGlvbiAzOiBpbiBzdGVwIDkuQi5p OiAiZGVub3RlZCIgLT4gImRlbGltaXRlZCI/DQoNCi0gc2VjdGlvbiA0OiBzdGVwIDI6ICJtZXRh ZGEiIC0+ICJtZXRhZGF0YSINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiANCj4gT2YgS2VudCBMZXVuZyAoa2xldW5nKQ0KPiBTZW50OiBUaHVyc2RheSwgU2Vw dGVtYmVyIDEyLCAyMDEzIDE6MjQgQU0NCj4gVG86IGNkbmlAaWV0Zi5vcmcNCj4gU3ViamVjdDog W0NETmldIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxldW5nLWNkbmkt dXJpLSANCj4gc2lnbmluZy0wMy50eHQNCj4gDQo+IEhpIGZvbGtzLiBCYXNlZCBvbiB0aGUgZGlz Y3Vzc2lvbnMgYXQgdGhlIGxhc3QgSUVURiBtZWV0aW5nLCBJ4oCZdmUgbWFkZSANCj4gdGhlIHVw ZGF0ZXMgdG8gdGhlIGRyYWZ0LiBTb21lIG9mIHRoZSBrZXkgY2hhbmdlcyB3ZXJlOg0KPiANCj4g LSBVcGRhdGVkIFVSSSBTaWduaW5nIGluIGEgQ0ROSSBFbnZpcm9ubWVudCBmaWd1cmUNCj4gLSBT cGVjaWZpZWQgdGhhdCBhdHRyaWJ1dGVzIGFkZGVkIGJ5IFVBL290aGVyICBlbnRpdHkgbmVlZCB0 byBiZSBhZnRlciANCj4gdGhlIENETkkgVVJJIFNpZ25pbmcgYXR0cmlidXRlDQo+IC0gVVJJIFNp Z25pbmcgVG9rZW4gYXR0cmlidXRlIHJlbmFtZWQgdG8gVVJJIFNpZ25pbmcgUGFja2FnZSANCj4g YXR0cmlidXRlLCB3aGljaCBpcyBub3cgbWFuZGF0b3J5DQo+IA0KPiBSZXZpZXcgY29tbWVudHMg YXJlIHdlbGNvbWUuIFRoYW5rcy4NCj4gDQo+IEtlbnQNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogRnJpZGF5LCBBdWd1c3QgMzAsIDIwMTMgMTI6 MzEgUE0NCj4gVG86IFJheSB2YW4gQnJhbmRlbmJ1cmc7IFNjb3R0IExlaWJyYW5kOyBLZW50IExl dW5nIChrbGV1bmcpOyBGcmFuY29pcyANCj4gTGUgRmF1Y2hldXIgKGZsZWZhdWNoKTsgQmlsbCBE b3duZXkNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gZHJhZnQt bGV1bmctY2RuaS11cmktc2lnbmluZy0wMy50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtbGV1bmctY2RuaS11cmktc2lnbmluZy0wMy50eHQNCj4gaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZW50IExldW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg DQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBGaWxlbmFtZToJIGRyYWZ0LWxldW5nLWNkbmktdXJpLXNp Z25pbmcNCj4gUmV2aXNpb246CSAwMw0KPiBUaXRsZToJCSBVUkkgU2lnbmluZyBmb3IgQ0ROIElu dGVyY29ubmVjdGlvbiAoQ0ROSSkNCj4gQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDgtMzANCj4gR3Jv dXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IE51bWJlciBvZiBwYWdlczogMzMNCj4gVVJM OiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1s ZXVuZy1jZG5pLXVyaS0NCj4gc2lnbmluZy0wMy50eHQNCj4gU3RhdHVzOiAgICAgICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxldW5nLWNkbmktdXJpLQ0KPiBzaWdu aW5nDQo+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bGV1bmctY2RuaS11cmktc2lnbmluZy0NCj4gMDMNCj4gRGlmZjogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1sZXVuZy1jZG5pLXVyaS0NCj4gc2lnbmlu Zy0wMw0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0 aGUgY29uY2VwdCBvZiBVUkkgc2lnbmluZyBzdXBwb3J0cyB0aGUNCj4gICAgY29udGVudCBhY2Nl c3MgY29udHJvbCByZXF1aXJlbWVudHMgb2YgQ0ROSSBhbmQgcHJvcG9zZXMgYSBjYW5kaWRhdGUN Cj4gICAgVVJJIHNpZ25pbmcgc2NoZW1lLg0KPiANCj4gICAgVGhlIHByb3Bvc2VkIFVSSSBzaWdu aW5nIG1ldGhvZCBzcGVjaWZpZXMgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCB0bw0KPiAgICBiZSBp bmNsdWRlZCBpbiB0aGUgVVJJIGFuZCB0aGUgYWxnb3JpdGhtIHVzZWQgdG8gYXV0aG9yaXplIGFu ZCB0bw0KPiAgICB2YWxpZGF0ZSBhY2Nlc3MgcmVxdWVzdCBmb3IgdGhlIGNvbnRlbnQgcmVmZXJl bmNlZCBieSB0aGUgVVJJLiAgU29tZQ0KPiAgICBvZiB0aGUgaW5mb3JtYXRpb24gbWF5IGJlIGFj Y2Vzc2VkIGJ5IHRoZSBDRE4gdmlhIGNvbmZpZ3VyYXRpb24gb3INCj4gICAgQ0ROSSBtZXRhZGF0 YS4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgDQo+IHRvb2xzLmlldGYu b3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENETmkgbWFpbGluZyBsaXN0DQo+IENE TmlAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5p DQo= From flefauch@cisco.com Tue Nov 5 08:12:34 2013 Return-Path: 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 4C72121E8237 for ; Tue, 5 Nov 2013 08:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.568 X-Spam-Level: X-Spam-Status: No, score=-10.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arhdmDy9C+uK for ; Tue, 5 Nov 2013 08:12:29 -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 0F2B821E8249 for ; Tue, 5 Nov 2013 08:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12434; q=dns/txt; s=iport; t=1383667949; x=1384877549; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4aKFh/L+89kSGPV72j0vIPWVNmrBdfh4Qxc9k96hAa8=; b=aq1tiieTrO4Isb22UuDo7I8RLib57iTDeD41eio1a0mkn+xe6CwaXfzm RJa9LrXLwhgyoHYoQTHjB4IxLqQdO60SK2fMg5srxN1coS3oxMXKRnRu3 dQSpbCAgKmrLzJ6HuSaQyCV7FkUwp8H6I0qEs+TrI5qGSQF1i3uouerUV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFALAXeVKtJXG8/2dsb2JhbABZgwc4U783gSwWdIIlAQEBAwEBAQFrCwUHBAIBGQQBAQEnBycLFAkIAgQBDQWHewYNvmOOIIE1BAcGgxqBDwOJCI8CkgmBaIE+gXE5 X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208,217";a="280940908" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2013 16:12:28 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA5GCSqW020293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 16:12:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 10:12:28 -0600 From: "Francois Le Faucheur (flefauch)" To: Jan Seedorf , Kevin Ma J Thread-Topic: Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics Thread-Index: AQHO2kHSWqFcGE5Ch02DZzYQ2FC3pA== Date: Tue, 5 Nov 2013 16:12:27 +0000 Message-ID: <89B634B5-60FA-4AE7-A924-B76D86096CC6@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.97.55] Content-Type: multipart/alternative; boundary="_000_89B634B560FA4AE7A924B76D86096CC6ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:12:34 -0000 --_000_89B634B560FA4AE7A924B76D86096CC6ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jan, Kevin, Did you consider the following? Can we discuss it in Vancouver? Tx On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) > wrote: Scott, Jan, and all, On 15 Oct 2013, at 11:30, Scott Leibrand > wrote: This feature (partial object caching) is absolutely a requirement before we= could think about offloading on-demand video traffic to a dCDN. If the dC= DN downloads the entire file, that completely ruins the uCDN's efforts to d= o partial caching, and the resulting increase in cache use makes things wor= se than not using a dCDN at all. Then perhaps it would make sense to include something like "Partial Object = Caching" in the set of capabilities that can be advertised in the CDNI Foot= print and Capabilities Advertisement interface (FCI). This would allow the = uCDN to select a dCDN that supports partial object caching when required (o= r possibly elect to serve itself). Jan, Would you mind including this as a candidate in your list so we rememebr to= make a concious decision about it? Thanks Francois -Scott On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van > wrote: Hi Ben, > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: maandag 14 oktober 2013 5:10 > To: Brandenburg, R. (Ray) van > Cc: cdni@ietf.org > Subject: Re: [CDNi] CDNI and byte-range requests > > Ray, > > On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: > > > Hi all, > > > > As I'm not sure whether this should be part of the Redirection Interfac= e > document or the Framework document, let me just post this as a general > question to the list: > > > > To my knowledge, the current CDNI documents do not explicitly address > the case of HTTP Byte-range requests. Although in most cases byte-range > requests will function just as any other requests, I think there are some= cases > where byte-range requests warrant further attention. An example is the > Redirection interface. If a uCDN asks a dCDN to deliver a particular user > request (containing a byte range), and the dCDN answers positively, can t= he > uCDN assume that the dCDN accepts any future requests for the same file > with a different byte range? And if that is the case, is this default beh= avior or > do we need an explicit flag in the inter-CDN redirection request to indic= ate > the uCDN/dCDN's preference? > > > > To be clear: I don't think we need any new functionality to handle byte= - > range requests, but a few sentences in either the Framework or the RI > document might clear up any future uncertainty. > > I don't see how this is any different to a sequence of non byte-range > requests. > > It will likely depend on the behaviour of the client (and possibly whethe= r the > server closes the connection after each request if that drives a differen= t > client behaviour) as to where the client ends up going (uCDN or dCDN) whe= n > it makes a subsequent request. > > Trying to say anything here may take us down the rat hole of trying to > describe client behaviour which we don't control. > Let me give a practical example: Let's say the uCDN is hosting a 2gb TS fil= e. At some point it receives an incoming request for a particular byte rang= e within that file, let's say the first 10mb. For some reason the uCDN deci= des that it wants to redirect the request to a dCDN. The dCDN receives the = request. At that point it has to decide what to do: does it download the fu= ll 2gb file from the uCDN, or does it download just the first 10mb? Of cour= se it's fully up to internal logic in the dCDN to decide what it should do = here, however it does have an impact on the uCDN as well (potentially unnec= essary traffic reducing the effectiveness of the inter-CDN redirect). My qu= estion is, do we need to say anything about this case to help both the dCDN= and uCDN in making this decision? Ray > Ben > > > > > Best regards, > > > > Ray > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_89B634B560FA4AE7A924B76D86096CC6ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0761FB78931F3641A611C0DFD255B844@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Jan, Kevin,

Did you consider the following?
Can we discuss it in Vancouver?

Tx

On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Scott, Jan, and all,

On 15 Oct 2013, at 11:30, Scott Leibrand <sleibrand@llnw.com> wrote:

This feature (partial object caching) is absolutely a requ= irement before we could think about offloading on-demand video traffic to a= dCDN.  If the dCDN downloads the entire file, that completely ruins t= he uCDN's efforts to do partial caching, and the resulting increase in cache use makes things worse than not using = a dCDN at all.

Then perhaps it would make sense to include something like "Parti= al Object Caching" in the set of capabilities that can be advertised i= n the CDNI Footprint and Capabilities Advertisement interface (FCI). This w= ould allow the uCDN to select a dCDN that supports partial object caching when required (or possibly elect to serve = itself).

Jan,
Would you mind including this as a candidate in your list so we rememe= br to make a concious decision about it?

Thanks

Francois




-Scott


On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R.= (Ray) van <ray.vanbrandenburg@tno.nl> wrote:
Hi Ben,

> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
> Sent: maandag 14 oktober 2013 5:10
> To: Brandenburg, R. (Ray) van
> Cc: cdni@ietf.org
> Subject: Re: [CDNi] CDNI and byte-range requests
>
> Ray,
>
> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote:
>
> > Hi all,
> >
> > As I'm not sure whether this should be part of the Redirection In= terface
> document or the Framework document, let me just post this as a general=
> question to the list:
> >
> > To my knowledge, the current CDNI documents do not explicitly add= ress
> the case of HTTP Byte-range requests. Although in most cases byte-rang= e
> requests will function just as any other requests, I think there are s= ome cases
> where byte-range requests warrant further attention. An example is the=
> Redirection interface. If a uCDN asks a dCDN to deliver a particular u= ser
> request (containing a byte range), and the dCDN answers positively, ca= n the
> uCDN assume that the dCDN accepts any future requests for the same fil= e
> with a different byte range? And if that is the case, is this default = behavior or
> do we need an explicit flag in the inter-CDN redirection request to in= dicate
> the uCDN/dCDN's preference?
> >
> > To be clear: I don't think we need any new functionality to handl= e byte-
> range requests, but a few sentences in either the Framework or the RI<= br> > document might clear up any future uncertainty.
>
> I don't see how this is any different to a sequence of non byte-range<= br> > requests.
>
> It will likely depend on the behaviour of the client (and possibly whe= ther the
> server closes the connection after each request if that drives a diffe= rent
> client behaviour) as to where the client ends up going (uCDN or dCDN) = when
> it makes a subsequent request.
>
> Trying to say anything here may take us down the rat hole of trying to=
> describe client behaviour which we don't control.
>

Let me give a practical example: Let's say the uCDN is hosting a 2gb TS fil= e. At some point it receives an incoming request for a particular byte rang= e within that file, let's say the first 10mb. For some reason the uCDN deci= des that it wants to redirect the request to a dCDN. The dCDN receives the request. At that point it has to = decide what to do: does it download the full 2gb file from the uCDN, or doe= s it download just the first 10mb? Of course it's fully up to internal logi= c in the dCDN to decide what it should do here, however it does have an impact on the uCDN as well (potent= ially unnecessary traffic reducing the effectiveness of the inter-CDN redir= ect). My question is, do we need to say anything about this case to help bo= th the dCDN and uCDN in making this decision?

Ray

> Ben
>
> >
> > Best regards,
> >
> > Ray
> > This e-mail and its contents are subject to the DISCLAIMER at
> http:/= /www.tno.nl/emaildisclaimer
> >
> > _______________________________________________
> > CDNi mailing list
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni

_______________________________________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni


--_000_89B634B560FA4AE7A924B76D86096CC6ciscocom_-- From kevin.ma@azukisystems.com Tue Nov 5 08:16:35 2013 Return-Path: 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 F1C8F21E8291 for ; Tue, 5 Nov 2013 08:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTlJdaT2jtBJ for ; Tue, 5 Nov 2013 08:16:08 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 40BE521E82A7 for ; Tue, 5 Nov 2013 08:16:00 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E7C4A55394D; Tue, 5 Nov 2013 11:15:57 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C1C5D5538FB; Tue, 5 Nov 2013 11:15:56 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Tue, 5 Nov 2013 11:15:56 -0500 From: Kevin J Ma To: "Francois Le Faucheur (flefauch)" , Jan Seedorf Date: Tue, 5 Nov 2013 11:15:53 -0500 Thread-Topic: Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics Thread-Index: AQHO2kHSWqFcGE5Ch02DZzYQ2FC3pJoWz/XA Message-ID: <291CC3F9E50E7641901A54E85D0977C6B027F5A1A2@MAILR002.mail.lan> References: <89B634B5-60FA-4AE7-A924-B76D86096CC6@cisco.com> In-Reply-To: <89B634B5-60FA-4AE7-A924-B76D86096CC6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C6B027F5A1A2MAILR002maill_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:16:36 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6B027F5A1A2MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable i did not consider it, but i am happy to discuss it. From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: Tuesday, November 05, 2013 11:12 AM To: Jan Seedorf; Kevin J Ma Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray); Fr= ancois Le Faucheur (flefauch); Larry Peterson; cdni@ietf.org; Daryl Malas Subject: Discussing a "Partial Caching" Capability (for byte-range requests= ) in FCI semantics Jan, Kevin, Did you consider the following? Can we discuss it in Vancouver? Tx On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) > wrote: Scott, Jan, and all, On 15 Oct 2013, at 11:30, Scott Leibrand > wrote: This feature (partial object caching) is absolutely a requirement before we= could think about offloading on-demand video traffic to a dCDN. If the dC= DN downloads the entire file, that completely ruins the uCDN's efforts to d= o partial caching, and the resulting increase in cache use makes things wor= se than not using a dCDN at all. Then perhaps it would make sense to include something like "Partial Object = Caching" in the set of capabilities that can be advertised in the CDNI Foot= print and Capabilities Advertisement interface (FCI). This would allow the = uCDN to select a dCDN that supports partial object caching when required (o= r possibly elect to serve itself). Jan, Would you mind including this as a candidate in your list so we rememebr to= make a concious decision about it? Thanks Francois -Scott On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van > wrote: Hi Ben, > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: maandag 14 oktober 2013 5:10 > To: Brandenburg, R. (Ray) van > Cc: cdni@ietf.org > Subject: Re: [CDNi] CDNI and byte-range requests > > Ray, > > On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: > > > Hi all, > > > > As I'm not sure whether this should be part of the Redirection Interfac= e > document or the Framework document, let me just post this as a general > question to the list: > > > > To my knowledge, the current CDNI documents do not explicitly address > the case of HTTP Byte-range requests. Although in most cases byte-range > requests will function just as any other requests, I think there are some= cases > where byte-range requests warrant further attention. An example is the > Redirection interface. If a uCDN asks a dCDN to deliver a particular user > request (containing a byte range), and the dCDN answers positively, can t= he > uCDN assume that the dCDN accepts any future requests for the same file > with a different byte range? And if that is the case, is this default beh= avior or > do we need an explicit flag in the inter-CDN redirection request to indic= ate > the uCDN/dCDN's preference? > > > > To be clear: I don't think we need any new functionality to handle byte= - > range requests, but a few sentences in either the Framework or the RI > document might clear up any future uncertainty. > > I don't see how this is any different to a sequence of non byte-range > requests. > > It will likely depend on the behaviour of the client (and possibly whethe= r the > server closes the connection after each request if that drives a differen= t > client behaviour) as to where the client ends up going (uCDN or dCDN) whe= n > it makes a subsequent request. > > Trying to say anything here may take us down the rat hole of trying to > describe client behaviour which we don't control. > Let me give a practical example: Let's say the uCDN is hosting a 2gb TS fil= e. At some point it receives an incoming request for a particular byte rang= e within that file, let's say the first 10mb. For some reason the uCDN deci= des that it wants to redirect the request to a dCDN. The dCDN receives the = request. At that point it has to decide what to do: does it download the fu= ll 2gb file from the uCDN, or does it download just the first 10mb? Of cour= se it's fully up to internal logic in the dCDN to decide what it should do = here, however it does have an impact on the uCDN as well (potentially unnec= essary traffic reducing the effectiveness of the inter-CDN redirect). My qu= estion is, do we need to say anything about this case to help both the dCDN= and uCDN in making this decision? Ray > Ben > > > > > Best regards, > > > > Ray > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_291CC3F9E50E7641901A54E85D0977C6B027F5A1A2MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

i did not consider it, but i am = happy to discuss it.

 

From: Francois Le Faucheur (flefau= ch) [mailto:flefauch@cisco.com]
Sent: Tuesday, November 05, 2013= 11:12 AM
To: Jan Seedorf; Kevin J Ma
Cc: Scott Leibran= d; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray); Francois Le Faucheu= r (flefauch); Larry Peterson; cdni@ietf.org; Daryl Malas
Subject:= Discussing a "Partial Caching" Capability (for byte-range reques= ts) in FCI semantics

=  

Jan, Kevin,

<= p class=3DMsoNormal> 

Di= d you consider the following?

Can we discuss it in Vancouver?

 

Tx

<= /div>

 

On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:



Scott, Jan, and all,

&= nbsp;

On 15 Oct 2013, at 11:30, Sco= tt Leibrand <sleibrand@llnw.com> wrote:





 

=

On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. = (Ray) van <ray.vanbrandenburg@tno.nl> wrote:

Hi Ben,


> -----Original Message-----
> From: Ben Niven-Jen= kins [mailto:ben@niven-jenkins.c= o.uk]
> Sent: maandag 14 oktober 2013 5:10
> To: Brandenbur= g, R. (Ray) van
> Cc: cdni@ietf.org<= /a>
> Subject: Re: [CDNi] CDNI and byte-range requests
>
>= ; Ray,
>
> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van = wrote:
>
> > Hi all,
> >
> > As I'm not su= re whether this should be part of the Redirection Interface
> documen= t or the Framework document, let me just post this as a general
> que= stion to the list:
> >
> > To my knowledge, the current C= DNI documents do not explicitly address
> the case of HTTP Byte-range= requests. Although in most cases byte-range
> requests will function= just as any other requests, I think there are some cases
> where byt= e-range requests warrant further attention. An example is the
> Redir= ection interface. If a uCDN asks a dCDN to deliver a particular user
>= ; request (containing a byte range), and the dCDN answers positively, can t= he
> uCDN assume that the dCDN accepts any future requests for the sa= me file
> with a different byte range? And if that is the case, is th= is default behavior or
> do we need an explicit flag in the inter-CDN= redirection request to indicate
> the uCDN/dCDN's preference?
>= ; >
> > To be clear: I don't think we need any new functionalit= y to handle byte-
> range requests, but a few sentences in either the= Framework or the RI
> document might clear up any future uncertainty= .
>
> I don't see how this is any different to a sequence of no= n byte-range
> requests.
>
> It will likely depend on the= behaviour of the client (and possibly whether the
> server closes th= e connection after each request if that drives a different
> client b= ehaviour) as to where the client ends up going (uCDN or dCDN) when
> = it makes a subsequent request.
>
> Trying to say anything here = may take us down the rat hole of trying to
> describe client behaviou= r which we don't control.
>

Let me give a practical example: Let's say the uCDN is hosting a 2gb = TS file. At some point it receives an incoming request for a particular byt= e range within that file, let's say the first 10mb. For some reason the uCD= N decides that it wants to redirect the request to a dCDN. The dCDN receive= s the request. At that point it has to decide what to do: does it download = the full 2gb file from the uCDN, or does it download just the first 10mb? O= f course it's fully up to internal logic in the dCDN to decide what it shou= ld do here, however it does have an impact on the uCDN as well (potentially= unnecessary traffic reducing the effectiveness of the inter-CDN redirect).= My question is, do we need to say anything about this case to help both th= e dCDN and uCDN in making this decision?
<= br>Ray

 

______________________________= _________________
CDNi mailing list
= CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

 

<= o:p> 

= --_000_291CC3F9E50E7641901A54E85D0977C6B027F5A1A2MAILR002maill_-- From Jan.Seedorf@neclab.eu Tue Nov 5 09:42:07 2013 Return-Path: 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 7F14211E821C for ; Tue, 5 Nov 2013 09:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfm-lVMSF5aX for ; Tue, 5 Nov 2013 09:42:02 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 85A7011E80F9 for ; Tue, 5 Nov 2013 09:41:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id ED27F105F1B for ; Tue, 5 Nov 2013 18:35:21 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKM-O-EZNGUG for ; Tue, 5 Nov 2013 18:35:21 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id CE603105EF8 for ; Tue, 5 Nov 2013 18:35:16 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.11]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 5 Nov 2013 18:40:58 +0100 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: CDNI FCI Semantics IANA Considerations side meeting at IETF-88 Thread-Index: Ac7aTOrfuDK2PtAHSFOLIOT/8MA71w== Date: Tue, 5 Nov 2013 17:40:58 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE639DABF0@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.212] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] CDNI FCI Semantics IANA Considerations side meeting at IETF-88 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:42:07 -0000 Dear all, The latest version of the FCI semantics draft contains a IANA Consideration= Section (see draft-ietf-cdni-footprint-capabilities-semantics-01). We (the= authors of the draft) will meet at this IETF-88 on THU over lunch to discu= ss this text. The purpose of this lunch meeting is to check that the text i= n the latest version of the CDNI FCI Semantics draft reflects our understan= ding and discussions from the Berlin meeting. We will meet at the Starbucks= in the Hyatt ground floor and then go for lunch somewhere. We will report = the outcome of the meeting in the CDNI session on THU afternoon. Anybody who is interested in this discussion please feel free to join. Perh= aps drop me a line so that we can wait for you. - Jan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan Seedorf Senior Researcher NEC Europe Ltd., NEC Laboratories Europe, Network Division=A0=A0=A0=A0=A0 Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 e-mail:=A0 jan.seedorf@neclab.eu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End = Road, London, HA4 6QE, GB, Registered in England 2832014 From Jan.Seedorf@neclab.eu Tue Nov 5 09:44:29 2013 Return-Path: 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 6E9D811E8212 for ; Tue, 5 Nov 2013 09:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6272AUdKBY01 for ; Tue, 5 Nov 2013 09:44:01 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 32BA511E8244 for ; Tue, 5 Nov 2013 09:43:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E7096105F1C; Tue, 5 Nov 2013 18:37:02 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv9+HZQTMRJA; Tue, 5 Nov 2013 18:37:02 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id C9B4D105EF8; Tue, 5 Nov 2013 18:36:27 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.11]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 5 Nov 2013 18:42:14 +0100 From: Jan Seedorf To: Kevin J Ma , "Francois Le Faucheur (flefauch)" Thread-Topic: Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics Thread-Index: AQHO2kHaSB5pCihU106+t4J5fkiggZoWv1KAgAAopGA= Date: Tue, 5 Nov 2013 17:42:13 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE639DAC05@PALLENE.office.hd> References: <89B634B5-60FA-4AE7-A924-B76D86096CC6@cisco.com> <291CC3F9E50E7641901A54E85D0977C6B027F5A1A2@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B027F5A1A2@MAILR002.mail.lan> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 17:44:30 -0000 Same here, we have not considered this, but sure let's discuss it during Th= ursday's lunch meeting - Jan > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Tuesday, November 05, 2013 5:16 PM > To: Francois Le Faucheur (flefauch); Jan Seedorf > Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray); > Larry Peterson; cdni@ietf.org; Daryl Malas > Subject: RE: Discussing a "Partial Caching" Capability (for byte-range > requests) in FCI semantics >=20 > i did not consider it, but i am happy to discuss it. >=20 >=20 >=20 > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Tuesday, November 05, 2013 11:12 AM > To: Jan Seedorf; Kevin J Ma > Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray); > Francois Le Faucheur (flefauch); Larry Peterson; cdni@ietf.org; Daryl Mal= as > Subject: Discussing a "Partial Caching" Capability (for byte-range reques= ts) in > FCI semantics >=20 >=20 >=20 > Jan, Kevin, >=20 >=20 >=20 > Did you consider the following? >=20 > Can we discuss it in Vancouver? >=20 >=20 >=20 > Tx >=20 >=20 >=20 > On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) > wrote: >=20 >=20 >=20 >=20 >=20 > Scott, Jan, and all, >=20 >=20 >=20 > On 15 Oct 2013, at 11:30, Scott Leibrand wrote: >=20 >=20 >=20 >=20 >=20 > This feature (partial object caching) is absolutely a requirement before = we > could think about offloading on-demand video traffic to a dCDN. If the d= CDN > downloads the entire file, that completely ruins the uCDN's efforts to do > partial caching, and the resulting increase in cache use makes things wor= se > than not using a dCDN at all. >=20 >=20 >=20 > Then perhaps it would make sense to include something like "Partial Objec= t > Caching" in the set of capabilities that can be advertised in the CDNI Fo= otprint > and Capabilities Advertisement interface (FCI). This would allow the uCDN= to > select a dCDN that supports partial object caching when required (or poss= ibly > elect to serve itself). >=20 >=20 >=20 > Jan, >=20 > Would you mind including this as a candidate in your list so we rememebr = to > make a concious decision about it? >=20 >=20 >=20 > Thanks >=20 >=20 >=20 > Francois >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -Scott >=20 >=20 >=20 > On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van > wrote: >=20 > Hi Ben, >=20 >=20 > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: maandag 14 oktober 2013 5:10 > > To: Brandenburg, R. (Ray) van > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] CDNI and byte-range requests > > > > Ray, > > > > On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: > > > > > Hi all, > > > > > > As I'm not sure whether this should be part of the Redirection Interf= ace > > document or the Framework document, let me just post this as a general > > question to the list: > > > > > > To my knowledge, the current CDNI documents do not explicitly address > > the case of HTTP Byte-range requests. Although in most cases byte-range > > requests will function just as any other requests, I think there are so= me > cases > > where byte-range requests warrant further attention. An example is the > > Redirection interface. If a uCDN asks a dCDN to deliver a particular us= er > > request (containing a byte range), and the dCDN answers positively, can > the > > uCDN assume that the dCDN accepts any future requests for the same file > > with a different byte range? And if that is the case, is this default b= ehavior > or > > do we need an explicit flag in the inter-CDN redirection request to ind= icate > > the uCDN/dCDN's preference? > > > > > > To be clear: I don't think we need any new functionality to handle by= te- > > range requests, but a few sentences in either the Framework or the RI > > document might clear up any future uncertainty. > > > > I don't see how this is any different to a sequence of non byte-range > > requests. > > > > It will likely depend on the behaviour of the client (and possibly whet= her > the > > server closes the connection after each request if that drives a differ= ent > > client behaviour) as to where the client ends up going (uCDN or dCDN) > when > > it makes a subsequent request. > > > > Trying to say anything here may take us down the rat hole of trying to > > describe client behaviour which we don't control. > > >=20 > Let me give a practical example: Let's say the uCDN is hosting a 2gb TS f= ile. At > some point it receives an incoming request for a particular byte range wi= thin > that file, let's say the first 10mb. For some reason the uCDN decides tha= t it > wants to redirect the request to a dCDN. The dCDN receives the request. A= t > that point it has to decide what to do: does it download the full 2gb fil= e from > the uCDN, or does it download just the first 10mb? Of course it's fully u= p to > internal logic in the dCDN to decide what it should do here, however it d= oes > have an impact on the uCDN as well (potentially unnecessary traffic reduc= ing > the effectiveness of the inter-CDN redirect). My question is, do we need = to > say anything about this case to help both the dCDN and uCDN in making thi= s > decision? >=20 > Ray >=20 >=20 > > Ben > > > > > > > > Best regards, > > > > > > Ray > > > This e-mail and its contents are subject to the DISCLAIMER at > > http://www.tno.nl/emaildisclaimer > > > > > > _______________________________________________ > > > CDNi mailing list > > > CDNi@ietf.org > > > https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 >=20 >=20 >=20 From iesg-secretary@ietf.org Tue Nov 5 12:35:02 2013 Return-Path: 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 CB6FC21E8097; Tue, 5 Nov 2013 12:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttUEn8JzynTu; Tue, 5 Nov 2013 12:35:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7FF11E813B; Tue, 5 Nov 2013 12:35:02 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131105203502.29554.40685.idtracker@ietfa.amsl.com> Date: Tue, 05 Nov 2013 12:35:02 -0800 Cc: cdni@ietf.org Subject: [CDNi] Last Call: (Content Distribution Network Interconnection (CDNI) Requirements) to Informational RFC X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 20:35:03 -0000 The IESG has received a request from the Content Delivery Networks Interconnection WG (cdni) to consider the following document: - 'Content Distribution Network Interconnection (CDNI) Requirements' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-11-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Content Delivery Networks (CDNs) are frequently used for content delivery. As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers and Enterprise Service Providers are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-cdni-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-cdni-requirements/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2124/ From flefauch@cisco.com Tue Nov 5 20:02:47 2013 Return-Path: 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 1D87121F9DAF for ; Tue, 5 Nov 2013 20:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ku3Xux6XMOAA for ; Tue, 5 Nov 2013 20:02:42 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C7D8411E81C3 for ; Tue, 5 Nov 2013 20:02:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13963; q=dns/txt; s=iport; t=1383710560; x=1384920160; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Xdr58+/O6e6LpaCdzaBJIp6Ien97gCglJXBcU+2l/+k=; b=aNzG/Okrimx/DsL7Nv0YkjKPE96u5oGyF1OT5AGTKYwcbCA8271ymO6C dgzLmWbdM3JXfcnmreHS3r4tyy/qKRQwYYvNB2wG7aNhoMzFHIfdgyeEN 6EQB1Bot5SiItQPTK4hyQS8HReNdplNKDqkzxodpqE9MEFz+5LQjg77p2 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAJa+eVKtJXG//2dsb2JhbABZgwc4TQa/TIElFnSCJQEBAQMBAQEBawsFCwIBGQMBAi8nCx0IAgQOBQmHcgYIBb5bj1kHBoMagQ8DlCuDX4EvkFqDJoIq X-IronPort-AV: E=Sophos;i="4.93,644,1378857600"; d="scan'208";a="278224899" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 06 Nov 2013 04:02:39 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA642dpk030523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 04:02:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 22:02:38 -0600 From: "Francois Le Faucheur (flefauch)" To: Ben Niven-Jenkins Thread-Topic: Coments on draft-ietf-cdni-redirection-01.txt Thread-Index: AQHO2qUIavDuC5mMWE2Nwm4lFYyAfw== Date: Wed, 6 Nov 2013 04:02:38 +0000 Message-ID: <38D49197-8105-4F01-B65D-A8E649F2C33E@cisco.com> References: <20131021093041.29508.98885.idtracker@ietfa.amsl.com> <0936B164-79A1-48D7-B702-3B98E8486861@niven-jenkins.co.uk> In-Reply-To: <0936B164-79A1-48D7-B702-3B98E8486861@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.189] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Coments on draft-ietf-cdni-redirection-01.txt 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 04:02:47 -0000 Ben and all, Some comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D *** OLD: " If the RI is used between the uCDN and one or more dCDNs. The dCDN's RI response may contain a Redirection Target ...=20 " NEW: " If the RI is used between the uCDN and one or more dCDNs, the dCDNs' RI response will typically contain a Redirection Target ...=20 " *** OLD: " where the attributes of a User Agent's requests are encapsulated along with any other data that can aid the downstream CDN in processing the requests. The RI response encapsulates the attributes " NEW: " where the attributes of a User Agent's requests are conveyed along with any other data that can aid the downstream CDN in processing the requests. The RI response conveys the attributes " [as discussed before, "encapsulates" incorrectly suggests they are conveyed= by embedding their native format] *** OLD: " To assist the routing decision of a Downstream CDN, the Upstream CDN shall convey as much information as possible to the Downstream CDN, for example the URI of the requested content and the User Agent's location information, when those are known by the uCDN Request Routing system. " NEW: " To assist the routing decision of a Downstream CDN, the Upstream CDN conveys the necessary information to the Downstream CDN, for example the URI of the requested content and the User Agent's location information, when those are known by the uCDN Request Routing system. Based on its policy, the Upstream CDN can decide to also= convey additional information about the request (e.g. HTTP request headers= ) to allow the Downstream CDN to make a more informed decision. " *** section 4.2, table illustrating "Top-Level keys in RI requests/response= s" The table (or the text that follow it) needs to indicate more exhaustively = which key is Mandatory or not (separately for request and for response). *** section 4.2, table illustrating "Top-Level keys in RI requests/response= s" "Transit CDNs should check the cdn-path and not cascade the RI request to d= ownstream CDNs that are already listed in cdn-path." This wording is redun= dant with some text further in teh document also discussing use of cdn-path= and it is not worded properly with RFC2119 keywords. I suggest removing it= from the table. *** OLD: " The dns dictionary of a RI request for DNS based redirection MUST contain the following keys: resolver-ip, qtype, qclass, qname and the value of each MUST be the value of the appropriate part of the User Agent's DNS query/request. " NEW: " The dns dictionary of a RI request for DNS based redirection MUST contain all the keys identified as Mandatory in the table above, and the value of each MUST be the value of the appropriate part of the User Agent's DNS query/request. " [In general, I think the doc needs a good clean-up to provide more exchaust= ive description of what is mandatory and what is not and better use of RFC2= 119 terminology] *** section 4.4.2 " For DNS based redirection the dCDN needs to return one of the following to the uCDN in the RI response: o The IP address of (or a CNAME to) the RT (if the dCDN is performing DNS based redirection); or o The IP address of (or a CNAME to) a RT which is a Request Router (if the dCDN is performing HTTP based redirection). " It is a little confusing to read that "for DNS-based redirection, the dCDN = needs to return =85 (if the dCDN is performing HTTP based redirection)". So= you need to distinguish more explicitely between the redirection method us= ed between the USer Agent & uCDN versus the redirection method used by the= dCDN. This probably affects also 4.4.1 (and 4.5) since its title refers t= o the redirection method used between the User Agent & uCDN. *** section 4.4.2 OLD: " Response must contain at least one of a, aaaa, cname. " NEW: " RI Response for DNS based redirection MUST contain all the keys identified = as Mandatory in the table above, as well as at least one of a, aaaa, cname. " *** section 4.4.2 why is the name in the response called "name" while it is called "name" in = the query? Should it not be also called "qname" (if it is always is equal t= o the qname of the query) or "rename" (if it can be different in some situa= tions)? *** OLD: " The http dictionary of a RI request for HTTP based redirection MUST contain the following keys: c-ip, cs-method, cs-version and cs-uri and the value of each MUST be the value of the appropriate part of the User Agent's DNS query/request. " NEW: " The http dictionary of a RI request for HTTP based redirection MUST contain all the keys identifed as Mandatory in the previous table and th= e value of each MUST be the value of the appropriate part of the User Agen= t's HTTP request. " *** section 4.6 " Additionally, an RI response MUST NOT be reused unless the request from the User Agent would generate an identical RI request to the dCDN as the one that resulted in the cached RI response. " This "MUST NOT" statement is immediately contradicted by the subsequent par= agraph introducing the notion of Scope. So it cannot stay as is. Also, you need to discuss the case of a request with everything identical e= xcept with different HTTP headers. That woudl generate a different RI reque= st, yet can you reuse a previous RI response or not? *** section 4.6: OLD: " "http": { "sc-status": 302, "cs-uri": "http://www.example.com" "sc-location": "http://sur1.dcdn.example/ucdn/example.com", " NEW: " "http": { "sc-status": 302, "cs-uri": "http://www.example.com/movie100.mp4" "sc-location": "http://sur1.dcdn.example/ucdn/example/movie100.mp4", " *** section 4.7: " [[Editor's note: We've tried to keep error specification light weight & provide the hooks needed to help with debugging without trying to be overly prescriptive=20 " I see the intent, but I don't get what you are proposing exactly: to not de= fine error values at all? to define a few only and allow implementations to= easily define others with (or without?) registering those before? Perhaps this could be achieved by creating a name based registry, with very= easy allocation of new names. *** section 4.8: In general, the text of that section could read better. There is overlap between the 3rd paragraph and the first one. OLD: " In order to prevent and detect RI request loops, each CDN MUST insert its CDN Provider ID into the cdn-path key of every RI request it originates or cascades. " NEW: " In order to prevent and detect RI request loops, each CDN MUST insert its CDN Provider ID into the cdn-path key of every RI request it originates, and MUST append its CDN Provider ID into the cdn-path key of= every RI request it cascades. " OLD: " Transit CDNs should check the cdn-path and not cascade the RI request to downstream CDNs that are already listed in cdn-path. CDNs MUST NOT propagate to any downstream CDNs if the number of CDN Provider IDs in cdn-path (including the CDN's own Provider ID) is equal to or greater than max-hops. " NEW: " Transit CDNs MUST check the cdn-path and not cascade the RI request to downstream CDNs that are already listed in cdn-path. CDNs MUST NOT propagate to any downstream CDNs if the number of CDN Provider IDs in cdn-path (after appending their own CDN Provider ID) is equal to or grea= ter than max-hops. " *** section 5: " Information passed over the RI could be considered personal or sensitive, for example RI requests contain parts of a User Agent's original request and RI responses reveal information about the dCDN's policy for which surrogates should serve which content/user locations. "=20 You can state after that paragraph, that a mitigation approach is for uCDN = RI implementation to support a policy that minimises the information convey= ed in the RI requests (or even possibly performs some anonimisation of the = client IP address). *** section 5: " The RI interface also provides a mechanism whereby a uCDN could probe a dCDN and infer the dCDN's edge topology by making repeated RI requests for different content and/or UA IP addresses and correlating the responses from the dCDN. Additionally the ability for a dCDN to indicate that a RI response applies more widely that the original request (via the scope dictionary) may significantly reduce the number of RI requests required to probe and infer the dCDN's edge topology. The same information could be obtained in the absence of the RI interface, but it could be more difficult to gather as it would require a distributed set of machines with a range of different IP addresses each making requests directly to the dCDN. However, the RI facilitates easier collection of such information as it enables a single client to query the dCDN for a redirection/surrogate selection on behalf of any UA IP address. " You could perhaps state that: * by definition, use of recursive redirection assumes that dCDN is willing= to provide more vsisbility to uCDN than with iterative.=20 * if that is a concern, dCDN could mitigate the problem by somewhat obfusc= ating the information returned (eg providing hostnames/CNAMEs that do not m= ap to surrogates 1 to 1), or could return RTs that are subject to a second = level resolution (eg regional Request Routers) which, pushed to the extreme= , effectively degrades back to iterative redirection. * section 5: When discussing benefits of using TLS, please clarifies TLS comes "for free= " thanks to the HTTP transport of RI. Also, mention TLS also provides integrity protection (e.g. a RI response ca= nnot be modified). Editos: =3D=3D=3D=3D=3D *** s/(RI) is one of the main building blocks/(RI) is one of the building b= locks/ *** s/it is down to the uCDN to decide/it is up to the uCDN to decide/ *** s/in this draft/in this document/ [multiple occurrences] *** s/and could be extended/and could be extended in future versions/ *** s/to help the Upstream CDN with future RI requests/to help the Upstream= CDN handle future RI requests/ *** allocate a TAble number to all the tables, for easier reference in the = text. *** s/cacheable & not stale/cacheable and not stale/ *** s/It should be noted that the loop detection & prevention mechanisms de= scribed above only cover preventing and detecting loops within the RI itsel= f./It should be noted that the loop detection and prevention mechanisms des= cribed above only prevents and detects loops within the RI itself./ *** s/As well as loops with the RI itself,/In addition to loops with the RI= itself,/ On 21 Oct 2013, at 11:27, Ben Niven-Jenkins wrote= : > Colleagues, >=20 > This is an update to the redirection interface specification to add addit= ional editorial text around data plane loop detection, media types to use, = the JSON encoding and the security considerations. >=20 > There are still some things outstanding within the document but any revie= w or suggestions for additional text would be most welcome :-) >=20 > Ben >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: 21 October 2013 10:30:41 GMT+01:00 >> To: i-d-announce@ietf.org >> Cc: cdni@ietf.org >> Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-01.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Content Delivery Networks Interconnecti= on Working Group of the IETF. >>=20 >> Title : Request Routing Redirection Interface for CDN Interco= nnection >> Author(s) : Wang Danhua >> Ben Niven-Jenkins >> He Xiaoyan >> Ge Chen >> Ni Wei >> Filename : draft-ietf-cdni-redirection-01.txt >> Pages : 24 >> Date : 2013-10-21 >>=20 >> Abstract: >> The Request Routing Interface comprises of (1) the asynchronous >> advertisement of footprint and capabilities by a downstream CDN that >> allows a upstream CDN to decide whether to redirect particular user >> requests to that downstream CDN; and (2) the synchronous operation of >> an upstream CDN requesting whether a downstream CDN is prepared to >> accept a user request and of a downstream CDN responding with how to >> actually redirect the user request. This document describes an >> interface for the latter part, i.e. the CDNI request routing/ >> Redirection Interface. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-cdni-redirection-01 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-redirection-01 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Tue Nov 5 20:02:47 2013 Return-Path: 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 32DB011E81C3 for ; Tue, 5 Nov 2013 20:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKUv7VBGGigv for ; Tue, 5 Nov 2013 20:02:42 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 282A211E811A for ; Tue, 5 Nov 2013 20:02:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2740; q=dns/txt; s=iport; t=1383710559; x=1384920159; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+ddeGZZXrSd/SPcLeswA3jBZ4ikNpVMjSU+ewfqQecM=; b=IY+k9Rh5F+wgskPQok0eJQ3k1qTeaaJvQpOv378It3SC/U3HSL33eDRm Rep8GJ3UrJcMJut9bbED92xreRitspbTP61UOPwXoGzQXl1sSFZAWMIkV SsNhLoSWblwPUKhSjqq+Yl18ExYya5saLRFhDV4T2sS/RFA3IoErWQouo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAEy+eVKtJV2d/2dsb2JhbABZgwc4Rwy/TIElFnSCJQEBAQMBcgcFCwIBTjIlAgQOBRqHYQYNvluOG4E+B4MggQ8DmAqBL5BagyaBaUE X-IronPort-AV: E=Sophos;i="4.93,643,1378857600"; d="scan'208";a="281235563" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 06 Nov 2013 04:02:39 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA642c8x025906 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Nov 2013 04:02:38 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 22:02:38 -0600 From: "Francois Le Faucheur (flefauch)" To: "Matt Caulfield (mcaulfie)" Thread-Topic: Comments on: draft-caulfield-cdni-rate-pacing-00.txt Thread-Index: AQHO2qUHGdFs28nKI0mRhVtKB8U8lA== Date: Wed, 6 Nov 2013 04:02:36 +0000 Message-ID: References: <201310221231.r9MCVZG08796@ftpeng-update.cisco.com> In-Reply-To: <201310221231.r9MCVZG08796@ftpeng-update.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.189] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Comments on: draft-caulfield-cdni-rate-pacing-00.txt 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 04:02:47 -0000 Hi Matt, 1) " No value needs to be advertised for this capability and therefore no additi= onal value registry need to be defined. " Would it be a good idea to define a value registry with a single value toda= y (e.g. "token-bucket/v1") to facilitate future extensibility in case it is= useful to define other rate-pacing methods (eg with a different algorithm,= with a max rate,=85)? 2) " 3.2. Request Routing Redirection Interface A new RatePacing metadata object is defined to represent the configuration for rate pacing.=20 " There seems to be some cut-and-paste issue or something as the RI section c= ontains text that is relevant to MI (and is a dupliacte of it). 3) " A malicious CSP might attempt to use rate pacing to instruct a dCDN to delivery some content at a very high rate thereby amplifying a DDOS attack. The decision to enforce a rate is left to the discretion of a dCDN. An implementation of rate pacing should implement reasonable upper bound to avoid such cases. " I don't get the issue. First, rate-pacing is only intended as an upper-limit when the dCDN is in a= position to send at a higher rate than that. It is not intended as an enco= uragement to send any faster dCDN would have transmitted otherwise. So to m= e, requesting a rate-pacing of infitine rate is simply equivalent to not us= ing rate-pacing at all.=20 Secondly, a CSP is typically charged by uCDN for dCDN deliveries. So if the= CSP is requesting uCDN/dCDN to transmit a lot of content as fast as possib= le, this is all good news for the uCDN and dCDN.=20 Cheers Francois On 22 Oct 2013, at 13:31, ietf-interest@cisco.com wrote: > You posted a new draft today. In the interest of informing your > Cisco colleagues, would you be so kind as to fill the rest of us > in on your project and what the draft is about? >=20 > The file may be found online at > http://tools.ietf.org/html/draft-caulfield-cdni-rate-pacing-00.txt. >=20 > By the way: if you know of a CPOL that might relate to this, > and you have not done so, would you please access > http://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register > the relationship between the CPOL and the draft? >=20 > The abstract you included reads: > Rate pacing is a class of network traffic shaping which limits the > transmission rate of data over a network. This document defines CDN= I > extensions for downstream CDNs to support rate pacing on behalf of > upstream CDNs. >=20 >=20 > There is more background at http://wwwin-people/fred/explanation.html >=20 > By the way, if you're not on ietf-interest, you may find it an > interesting list to join. >=20 From mcaulfie@cisco.com Tue Nov 5 20:18:42 2013 Return-Path: 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 C38E511E817D for ; Tue, 5 Nov 2013 20:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl7l7sm0vTka for ; Tue, 5 Nov 2013 20:18:38 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DA01311E811D for ; Tue, 5 Nov 2013 20:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4166; q=dns/txt; s=iport; t=1383711518; x=1384921118; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PU1BOIYUXjgki/S6zl7cswu50eGrCj1J/JbBNOkB540=; b=RwBIbAszfKP9EHP6e/ioPvmfS9olxmzDcI8pGG0AUbDj12d2VrpxokcU JL5e1QnBMCD/akLJ6yqayZJzEZKgZAInfueYxxxinqmnTF6k2ejH2+XCH TV1radfKJfgSylwUQy5SwyuUugXpNWf1SbzL6EEsLtNZ6+AiGR8XAmQn9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFANLBeVKtJXG8/2dsb2JhbABZgwc4Rwy/TIElFnSCJQEBAQMBOjgHBQcEAgEIEQQBAQsUEDIdCAIEDgUIEodhBg2+SI4bgQ0xBwaDGoEPA5k5kFqDJoFpQQ X-IronPort-AV: E=Sophos;i="4.93,644,1378857600"; d="scan'208";a="281029146" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 06 Nov 2013 04:18:31 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA64IUMq030441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Nov 2013 04:18:30 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 22:18:30 -0600 From: "Matt Caulfield (mcaulfie)" To: "Francois Le Faucheur (flefauch)" Thread-Topic: Comments on: draft-caulfield-cdni-rate-pacing-00.txt Thread-Index: AQHO2qUIt+E9W+zNmUaTum/19P1lW5oXlbHw Date: Wed, 6 Nov 2013 04:18:30 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C921DDEB52C@xmb-aln-x03.cisco.com> References: <201310221231.r9MCVZG08796@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.157] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on: draft-caulfield-cdni-rate-pacing-00.txt 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 04:18:43 -0000 Hi Francois, Thank you for the comments. Please see my responses inline.=09 Regards, Matt -----Original Message----- From: Francois Le Faucheur (flefauch)=20 Sent: Tuesday, November 05, 2013 8:03 PM To: Matt Caulfield (mcaulfie) Cc: cdni@ietf.org Subject: Comments on: draft-caulfield-cdni-rate-pacing-00.txt=20 Hi Matt, 1) " No value needs to be advertised for this capability and therefore no additi= onal value registry need to be defined. " Would it be a good idea to define a value registry with a single value toda= y (e.g. "token-bucket/v1") to facilitate future extensibility in case it is= useful to define other rate-pacing methods (eg with a different algorithm,= with a max rate,...)? [Matt] I think there are two options: 1) Change this rate pacing draft to m= ake it more extensible and define a registry as your describe, or 2) Change= the name of this draft to CDNI Token Bucket Rate Pacing and require that p= roponents of alternative rate pacing algorithms create their own drafts. Wh= ich is better from an IETF perspective? 2) " 3.2. Request Routing Redirection Interface A new RatePacing metadata object is defined to represent the configuration for rate pacing.=20 " There seems to be some cut-and-paste issue or something as the RI section c= ontains text that is relevant to MI (and is a dupliacte of it). [Matt] Yes, definitely a cut-and-paste issue. I will fix that in the next r= evision. The text should have been: " The RRI is not impacted by rate pacing. However, if the metadata for a pi= ece of content indicates that rate pacing is desired, then a request router= should only redirect requests for that content to CDNs which advertise "Ra= tePacing" as a capability." 3) " A malicious CSP might attempt to use rate pacing to instruct a dCDN to delivery some content at a very high rate thereby amplifying a DDOS attack. The decision to enforce a rate is left to the discretion of a dCDN. An implementation of rate pacing should implement reasonable upper bound to avoid such cases. " I don't get the issue. First, rate-pacing is only intended as an upper-limit when the dCDN is in a= position to send at a higher rate than that. It is not intended as an enco= uragement to send any faster dCDN would have transmitted otherwise. So to m= e, requesting a rate-pacing of infitine rate is simply equivalent to not us= ing rate-pacing at all.=20 Secondly, a CSP is typically charged by uCDN for dCDN deliveries. So if the= CSP is requesting uCDN/dCDN to transmit a lot of content as fast as possib= le, this is all good news for the uCDN and dCDN.=20 [Matt] Good points - I think I can remove this security consideration. Howe= ver, regarding rate pacing as only an upper limit - this is never stated ex= plicitly. Should we call this out in the draft? Right now, section #2 inclu= des the phrase: " the traffic shape MUST fit within the same envelope of a = token bucket algorithm."=20 Cheers Francois On 22 Oct 2013, at 13:31, ietf-interest@cisco.com wrote: > You posted a new draft today. In the interest of informing your Cisco=20 > colleagues, would you be so kind as to fill the rest of us in on your=20 > project and what the draft is about? >=20 > The file may be found online at > http://tools.ietf.org/html/draft-caulfield-cdni-rate-pacing-00.txt. >=20 > By the way: if you know of a CPOL that might relate to this, and you=20 > have not done so, would you please access=20 > http://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register the=20 > relationship between the CPOL and the draft? >=20 > The abstract you included reads: > Rate pacing is a class of network traffic shaping which limits the > transmission rate of data over a network. This document defines CDN= I > extensions for downstream CDNs to support rate pacing on behalf of > upstream CDNs. >=20 >=20 > There is more background at http://wwwin-people/fred/explanation.html >=20 > By the way, if you're not on ietf-interest, you may find it an=20 > interesting list to join. >=20 From sleibrand@llnw.com Tue Nov 5 20:25:52 2013 Return-Path: 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 944BF21E80DC for ; Tue, 5 Nov 2013 20:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTUfUtKWkb7L for ; Tue, 5 Nov 2013 20:25:47 -0800 (PST) Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by ietfa.amsl.com (Postfix) with ESMTP id A5BF221E80CA for ; Tue, 5 Nov 2013 20:25:47 -0800 (PST) Received: from mail-pd0-f180.google.com ([209.85.192.180]) (using TLSv1) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKUnnEy5T4IQrkEj1CLqON/+wOsC6ZSoM3@postini.com; Tue, 05 Nov 2013 20:25:47 PST Received: by mail-pd0-f180.google.com with SMTP id p10so9510007pdj.25 for ; Tue, 05 Nov 2013 20:25:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=QPTjzNtRprRCKbZSHZyZf8sFrlSvvuHsXBHMqQZZ4Sw=; b=A2Tak0T0EMk0ntEV2Q8NU2dUOBvjSEyF8JZjgvAPSVqUVospCZNCHcTUloeHmlaToW ERakCnHaQFSf80YTN7AkdXXs6UU0yWTj1oLSXx9v3IgyGeBo2nVJQh5bbaeaVVL8pMot Pg4Aa05AkwBHQMI1bp3uEl7Rj5Son5mMquwrq7rZ4u+ZeduEB7RF2vwz18q2jqiPf48t BHdeTnxL+1HvZE7imr9olFVEDz0eo8a3Nj4Z//c+qaKXBSpjMhdYhlz/MhIF/ukUNWXo +1EvkcuoRyr0VYUm462wx8TvB1OlVWn7fwJT2HKttpipE/zyY7ofpkWSZienhiy3OmMj IEMQ== X-Gm-Message-State: ALoCoQlmCEBU5tsCkffzZR8OIebTdh6gyHsLY8DSOPBO0h5bY6/+XEs5wntsJ2GF2VZy2GeaxpXh7kmGYIcp3eZpdeglR1yxva4QxKqLY6jJLoOz+ddiQtvxQz0aT2mtHVS9V8XLRsFgPsmG7Y6noDCNs/EMNX1Kjw== X-Received: by 10.66.163.164 with SMTP id yj4mr1821449pab.91.1383711946766; Tue, 05 Nov 2013 20:25:46 -0800 (PST) X-Received: by 10.66.163.164 with SMTP id yj4mr1821435pab.91.1383711946549; Tue, 05 Nov 2013 20:25:46 -0800 (PST) Received: from [10.232.179.246] (mobile-166-137-178-089.mycingular.net. [166.137.178.89]) by mx.google.com with ESMTPSA id b3sm38178094pbu.38.2013.11.05.20.25.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 20:25:45 -0800 (PST) References: <201310221231.r9MCVZG08796@ftpeng-update.cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <09AC97C8-30BD-4DE0-84AD-4D80F4F54969@llnw.com> X-Mailer: iPhone Mail (11B511) From: Scott Leibrand Date: Tue, 5 Nov 2013 20:25:44 -0800 To: "Francois Le Faucheur (flefauch)" Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on: draft-caulfield-cdni-rate-pacing-00.txt 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 04:25:52 -0000 > On Nov 5, 2013, at 8:02 PM, "Francois Le Faucheur (flefauch)" wrote: >=20 > Hi Matt,=20 >=20 > 3) > " > A malicious CSP might attempt to use rate pacing to instruct a dCDN > to delivery some content at a very high rate thereby amplifying a > DDOS attack. The decision to enforce a rate is left to the > discretion of a dCDN. An implementation of rate pacing should > implement reasonable upper bound to avoid such cases. > " > I don't get the issue. >=20 > First, rate-pacing is only intended as an upper-limit when the dCDN is in a= position to send at a higher rate than that. It is not intended as an encou= ragement to send any faster dCDN would have transmitted otherwise. So to me,= requesting a rate-pacing of infitine rate is simply equivalent to not using= rate-pacing at all.=20 >=20 > Secondly, a CSP is typically charged by uCDN for dCDN deliveries. So if th= e CSP is requesting uCDN/dCDN to transmit a lot of content as fast as possib= le, this is all good news for the uCDN and dCDN.=20 >=20 The problem is actually the reverse. If the CSP wants to DDoS the CDN, they c= an actually set the pacing to an absolute trickle. That leaves too many conn= ections open on the CDN's servers, thereby exhausting server state resources= . To prevent that, CDNs can configure a minimum pacing rate that they will h= onor.=20 -Scott >=20 > Cheers >=20 > Francois >=20 >=20 >> On 22 Oct 2013, at 13:31, ietf-interest@cisco.com wrote: >>=20 >> You posted a new draft today. In the interest of informing your >> Cisco colleagues, would you be so kind as to fill the rest of us >> in on your project and what the draft is about? >>=20 >> The file may be found online at >> http://tools.ietf.org/html/draft-caulfield-cdni-rate-pacing-00.txt. >>=20 >> By the way: if you know of a CPOL that might relate to this, >> and you have not done so, would you please access >> http://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register >> the relationship between the CPOL and the draft? >>=20 >> The abstract you included reads: >> Rate pacing is a class of network traffic shaping which limits the >> transmission rate of data over a network. This document defines CDNI= >> extensions for downstream CDNs to support rate pacing on behalf of >> upstream CDNs. >>=20 >>=20 >> There is more background at http://wwwin-people/fred/explanation.html >>=20 >> By the way, if you're not on ietf-interest, you may find it an >> interesting list to join. >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Tue Nov 5 20:39:15 2013 Return-Path: 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 CDAE921E80A9 for ; Tue, 5 Nov 2013 20:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n43-k+LNWxoJ for ; Tue, 5 Nov 2013 20:39:11 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9218721E80DC for ; Tue, 5 Nov 2013 20:39:11 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id EAAF85538FB; Tue, 5 Nov 2013 23:39:10 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2F782553704; Tue, 5 Nov 2013 23:39:10 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Tue, 5 Nov 2013 23:39:10 -0500 From: Kevin J Ma To: "Matt Caulfield (mcaulfie)" , "Francois Le Faucheur (flefauch)" Date: Tue, 5 Nov 2013 23:39:03 -0500 Thread-Topic: [CDNi] Comments on: draft-caulfield-cdni-rate-pacing-00.txt Thread-Index: AQHO2qUIt+E9W+zNmUaTum/19P1lW5oXlbHwgAAG4wA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6B027F5A54D@MAILR002.mail.lan> References: <201310221231.r9MCVZG08796@ftpeng-update.cisco.com> <166EBB70C264A9479E459B01B1BA6C921DDEB52C@xmb-aln-x03.cisco.com> In-Reply-To: <166EBB70C264A9479E459B01B1BA6C921DDEB52C@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on: draft-caulfield-cdni-rate-pacing-00.txt 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 04:39:15 -0000 > to define other rate-pacing methods (eg with a different > algorithm, with a max rate,...)? > > [Matt] I think there are two options: 1) Change this rate pacing draft to > make it more extensible and define a registry as your describe, or 2) > Change the name of this draft to CDNI Token Bucket Rate Pacing and requir= e > that proponents of alternative rate pacing algorithms create their own > drafts. Which is better from an IETF perspective? ... > [Matt] ... Right now, > section #2 includes the phrase: " the traffic shape MUST fit within the > same envelope of a token bucket algorithm." I actually found the "MUST fit within the same envelope" part confusing the first time i read through the draft. If the intent is to have all the dCDN= s provide substantially the same functionality, then I think it would be bett= er to make the GenericMetadata object associated with this capability token bucket specific. I initially interpreted the generic "rate" and "size" properties to be applicable to any random algorithm which may not have the same envelope as a token bucket. Another option might be to have a registr= y of allowable groups of algorithms with acceptably similar performance envel= opes, though that may be going a bit far? ;) -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Matt Caulfield (mcaulfie) > Sent: Tuesday, November 05, 2013 11:19 PM > To: Francois Le Faucheur (flefauch) > Cc: cdni@ietf.org > Subject: Re: [CDNi] Comments on: draft-caulfield-cdni-rate-pacing-00.txt >=20 > Hi Francois, >=20 > Thank you for the comments. Please see my responses inline. >=20 > Regards, > Matt >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch) > Sent: Tuesday, November 05, 2013 8:03 PM > To: Matt Caulfield (mcaulfie) > Cc: cdni@ietf.org > Subject: Comments on: draft-caulfield-cdni-rate-pacing-00.txt >=20 > Hi Matt, >=20 >=20 > 1) > " > No value needs to be advertised for this capability and therefore no > additional value registry need to be defined. > " > Would it be a good idea to define a value registry with a single value > today (e.g. "token-bucket/v1") to facilitate future extensibility in case > it is useful to define other rate-pacing methods (eg with a different > algorithm, with a max rate,...)? >=20 > [Matt] I think there are two options: 1) Change this rate pacing draft to > make it more extensible and define a registry as your describe, or 2) > Change the name of this draft to CDNI Token Bucket Rate Pacing and requir= e > that proponents of alternative rate pacing algorithms create their own > drafts. Which is better from an IETF perspective? >=20 >=20 > 2) > " > 3.2. Request Routing Redirection Interface > A new RatePacing metadata object is defined to represent the > configuration for rate pacing. > " > There seems to be some cut-and-paste issue or something as the RI section > contains text that is relevant to MI (and is a dupliacte of it). >=20 > [Matt] Yes, definitely a cut-and-paste issue. I will fix that in the next > revision. The text should have been: > " The RRI is not impacted by rate pacing. However, if the metadata for a > piece of content indicates that rate pacing is desired, then a request > router should only redirect requests for that content to CDNs which > advertise "RatePacing" as a capability." >=20 >=20 > 3) > " > A malicious CSP might attempt to use rate pacing to instruct a dCDN > to delivery some content at a very high rate thereby amplifying a > DDOS attack. The decision to enforce a rate is left to the > discretion of a dCDN. An implementation of rate pacing should > implement reasonable upper bound to avoid such cases. > " > I don't get the issue. >=20 > First, rate-pacing is only intended as an upper-limit when the dCDN is in > a position to send at a higher rate than that. It is not intended as an > encouragement to send any faster dCDN would have transmitted otherwise. S= o > to me, requesting a rate-pacing of infitine rate is simply equivalent to > not using rate-pacing at all. >=20 > Secondly, a CSP is typically charged by uCDN for dCDN deliveries. So if > the CSP is requesting uCDN/dCDN to transmit a lot of content as fast as > possible, this is all good news for the uCDN and dCDN. >=20 > [Matt] Good points - I think I can remove this security consideration. > However, regarding rate pacing as only an upper limit - this is never > stated explicitly. Should we call this out in the draft? Right now, > section #2 includes the phrase: " the traffic shape MUST fit within the > same envelope of a token bucket algorithm." >=20 >=20 > Cheers >=20 > Francois >=20 >=20 > On 22 Oct 2013, at 13:31, ietf-interest@cisco.com wrote: >=20 > > You posted a new draft today. In the interest of informing your Cisco > > colleagues, would you be so kind as to fill the rest of us in on your > > project and what the draft is about? > > > > The file may be found online at > > http://tools.ietf.org/html/draft-caulfield-cdni-rate-pacing-00.txt. > > > > By the way: if you know of a CPOL that might relate to this, and you > > have not done so, would you please access > > http://wwwin-eng.cisco.com/pcb/standards/csrt.cgi to register the > > relationship between the CPOL and the draft? > > > > The abstract you included reads: > > Rate pacing is a class of network traffic shaping which limits the > > transmission rate of data over a network. This document defines > CDNI > > extensions for downstream CDNs to support rate pacing on behalf of > > upstream CDNs. > > > > > > There is more background at http://wwwin-people/fred/explanation.html > > > > By the way, if you're not on ietf-interest, you may find it an > > interesting list to join. > > >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Tue Nov 5 20:54:38 2013 Return-Path: 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 47F0411E81F9 for ; Tue, 5 Nov 2013 20:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fFrfQeWtJe3 for ; Tue, 5 Nov 2013 20:54:33 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 5800111E8131 for ; Tue, 5 Nov 2013 20:54:33 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id F1FD67AE1B6; Tue, 5 Nov 2013 23:54:32 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2E3FF7ADEBC; Tue, 5 Nov 2013 23:54:32 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 5 Nov 2013 23:54:31 -0500 From: Kevin J Ma To: Jan Seedorf , "Francois Le Faucheur (flefauch)" Date: Tue, 5 Nov 2013 23:54:26 -0500 Thread-Topic: Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics Thread-Index: AQHO2kHaSB5pCihU106+t4J5fkiggZoWv1KAgAAopGCAALiXsA== Message-ID: <291CC3F9E50E7641901A54E85D0977C6B027F5A550@MAILR002.mail.lan> References: <89B634B5-60FA-4AE7-A924-B76D86096CC6@cisco.com> <291CC3F9E50E7641901A54E85D0977C6B027F5A1A2@MAILR002.mail.lan> <2779C9F0771F974CAD742BAE6D9904FE639DAC05@PALLENE.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE639DAC05@PALLENE.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 04:54:38 -0000 I have a couple clarifying questions about the partial caching: 1. Is there text somewhere that states that dCDNs MUST only cache what the client requested? Just because the dCDN is capable of partial caching, doesnt mean that it won't go ahead and ask for the whole file? 2. If we assume the dCDN only does partial acquisition requests, when it receives a partial delivery request, then my question is, are we concerned that dCDN is incapable of doing range requests? If so, should that not show up in the acquisition protocol capability? It's unclear to me what information the partial caching capability is actually conveying? 3. If what we really want is a way for the uCDN to tell the dCDN whether or not to use partial caching for a given piece of content, then I would think what we need is a new metadata object, not a new capability? thanx. -- Kevin J. Ma > -----Original Message----- > From: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] > Sent: Tuesday, November 05, 2013 12:42 PM > To: Kevin J Ma; Francois Le Faucheur (flefauch) > Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray); > Larry Peterson; cdni@ietf.org; Daryl Malas > Subject: RE: Discussing a "Partial Caching" Capability (for byte-range > requests) in FCI semantics >=20 > Same here, we have not considered this, but sure let's discuss it during > Thursday's lunch meeting >=20 > - Jan >=20 > > -----Original Message----- > > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > > Sent: Tuesday, November 05, 2013 5:16 PM > > To: Francois Le Faucheur (flefauch); Jan Seedorf > > Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray)= ; > > Larry Peterson; cdni@ietf.org; Daryl Malas > > Subject: RE: Discussing a "Partial Caching" Capability (for byte-range > > requests) in FCI semantics > > > > i did not consider it, but i am happy to discuss it. > > > > > > > > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > > Sent: Tuesday, November 05, 2013 11:12 AM > > To: Jan Seedorf; Kevin J Ma > > Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray)= ; > > Francois Le Faucheur (flefauch); Larry Peterson; cdni@ietf.org; Daryl > Malas > > Subject: Discussing a "Partial Caching" Capability (for byte-range > requests) in > > FCI semantics > > > > > > > > Jan, Kevin, > > > > > > > > Did you consider the following? > > > > Can we discuss it in Vancouver? > > > > > > > > Tx > > > > > > > > On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) > > wrote: > > > > > > > > > > > > Scott, Jan, and all, > > > > > > > > On 15 Oct 2013, at 11:30, Scott Leibrand wrote: > > > > > > > > > > > > This feature (partial object caching) is absolutely a requirement befor= e > we > > could think about offloading on-demand video traffic to a dCDN. If the > dCDN > > downloads the entire file, that completely ruins the uCDN's efforts to > do > > partial caching, and the resulting increase in cache use makes things > worse > > than not using a dCDN at all. > > > > > > > > Then perhaps it would make sense to include something like "Partial > Object > > Caching" in the set of capabilities that can be advertised in the CDNI > Footprint > > and Capabilities Advertisement interface (FCI). This would allow the > uCDN to > > select a dCDN that supports partial object caching when required (or > possibly > > elect to serve itself). > > > > > > > > Jan, > > > > Would you mind including this as a candidate in your list so we rememeb= r > to > > make a concious decision about it? > > > > > > > > Thanks > > > > > > > > Francois > > > > > > > > > > > > > > > > > > > > > > > > -Scott > > > > > > > > On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van > > wrote: > > > > Hi Ben, > > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: maandag 14 oktober 2013 5:10 > > > To: Brandenburg, R. (Ray) van > > > Cc: cdni@ietf.org > > > Subject: Re: [CDNi] CDNI and byte-range requests > > > > > > Ray, > > > > > > On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: > > > > > > > Hi all, > > > > > > > > As I'm not sure whether this should be part of the Redirection > Interface > > > document or the Framework document, let me just post this as a genera= l > > > question to the list: > > > > > > > > To my knowledge, the current CDNI documents do not explicitly > address > > > the case of HTTP Byte-range requests. Although in most cases byte- > range > > > requests will function just as any other requests, I think there are > some > > cases > > > where byte-range requests warrant further attention. An example is th= e > > > Redirection interface. If a uCDN asks a dCDN to deliver a particular > user > > > request (containing a byte range), and the dCDN answers positively, > can > > the > > > uCDN assume that the dCDN accepts any future requests for the same > file > > > with a different byte range? And if that is the case, is this default > behavior > > or > > > do we need an explicit flag in the inter-CDN redirection request to > indicate > > > the uCDN/dCDN's preference? > > > > > > > > To be clear: I don't think we need any new functionality to handle > byte- > > > range requests, but a few sentences in either the Framework or the RI > > > document might clear up any future uncertainty. > > > > > > I don't see how this is any different to a sequence of non byte-range > > > requests. > > > > > > It will likely depend on the behaviour of the client (and possibly > whether > > the > > > server closes the connection after each request if that drives a > different > > > client behaviour) as to where the client ends up going (uCDN or dCDN) > > when > > > it makes a subsequent request. > > > > > > Trying to say anything here may take us down the rat hole of trying t= o > > > describe client behaviour which we don't control. > > > > > > > Let me give a practical example: Let's say the uCDN is hosting a 2gb TS > file. At > > some point it receives an incoming request for a particular byte range > within > > that file, let's say the first 10mb. For some reason the uCDN decides > that it > > wants to redirect the request to a dCDN. The dCDN receives the request. > At > > that point it has to decide what to do: does it download the full 2gb > file from > > the uCDN, or does it download just the first 10mb? Of course it's fully > up to > > internal logic in the dCDN to decide what it should do here, however it > does > > have an impact on the uCDN as well (potentially unnecessary traffic > reducing > > the effectiveness of the inter-CDN redirect). My question is, do we nee= d > to > > say anything about this case to help both the dCDN and uCDN in making > this > > decision? > > > > Ray > > > > > > > Ben > > > > > > > > > > > Best regards, > > > > > > > > Ray > > > > This e-mail and its contents are subject to the DISCLAIMER at > > > http://www.tno.nl/emaildisclaimer > > > > > > > > _______________________________________________ > > > > CDNi mailing list > > > > CDNi@ietf.org > > > > https://www.ietf.org/mailman/listinfo/cdni > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > > > > > > > > From sleibrand@llnw.com Tue Nov 5 22:59:58 2013 Return-Path: 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 778FB21E80D1 for ; Tue, 5 Nov 2013 22:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSf2FirPCkE9 for ; Tue, 5 Nov 2013 22:59:54 -0800 (PST) Received: from exprod5og112.obsmtp.com (exprod5og112.obsmtp.com [64.18.0.24]) by ietfa.amsl.com (Postfix) with ESMTP id CA14021E80C2 for ; Tue, 5 Nov 2013 22:59:53 -0800 (PST) Received: from mail-ie0-f169.google.com ([209.85.223.169]) (using TLSv1) by exprod5ob112.postini.com ([64.18.4.12]) with SMTP ID DSNKUnno6WK2h86jezSWUq+dObBzLH6M4QNh@postini.com; Tue, 05 Nov 2013 22:59:53 PST Received: by mail-ie0-f169.google.com with SMTP id ar20so17338330iec.28 for ; Tue, 05 Nov 2013 22:59:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=vh2MBEa0HjINE8EpffjzBN7umAefUmhyR66ylqkg7k8=; b=KU/mjSPkirfYTGAE0fkaTGTDhYyPPn/in5EwfXBUQ/iXAJniJMM6ozZyh7NM07dNty izTYL/l3Wq/njZnf9A1+GgxyHaAGfP+7YjYua7GxrZPfC5AQExXieSAyC0PtMGGrJ+U5 qZJtRJSa+usGGIXGqzR4AhL78CBK1IUphmQH75Rb86QSGv493LFdLbRP0uPfijTzxxkg Ka8iVatuc/DCUz24F8QMaIWIK1+87h0vKvHn6pRsxv+SkvOVPNyGtx5QYP22ASDyiB5l 2hdnHszoc1A0zf4bLTL40EVSTnQd+fQKQVMs0ixyoYyLSCvh3zUt0gzztZ8RBXliQ1Wx zOmg== X-Gm-Message-State: ALoCoQkG+kN+DExxjtixVgJ4zm/t+0NxXWtP9qNzC9jRjbraPB5RtQkS08Wt6tS0Rx5qAe1wlqyJk1p6jvKaP0fiGWf1V8VVOGQGgRCEsirPtkig2rilLGdSfNTr88dTvPIiy+rMzxs2OHCl6yNsMrfgzZyEv4iLPg== X-Received: by 10.50.77.83 with SMTP id q19mr1225930igw.21.1383721193102; Tue, 05 Nov 2013 22:59:53 -0800 (PST) X-Received: by 10.50.77.83 with SMTP id q19mr1225918igw.21.1383721192830; Tue, 05 Nov 2013 22:59:52 -0800 (PST) Received: from [10.0.1.20] (c-67-170-42-95.hsd1.wa.comcast.net. [67.170.42.95]) by mx.google.com with ESMTPSA id ka5sm12726112igb.2.2013.11.05.22.59.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 22:59:51 -0800 (PST) References: <89B634B5-60FA-4AE7-A924-B76D86096CC6@cisco.com> <291CC3F9E50E7641901A54E85D0977C6B027F5A1A2@MAILR002.mail.lan> <2779C9F0771F974CAD742BAE6D9904FE639DAC05@PALLENE.office.hd> <291CC3F9E50E7641901A54E85D0977C6B027F5A550@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B027F5A550@MAILR002.mail.lan> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (11B511) From: Scott Leibrand Date: Tue, 5 Nov 2013 22:59:49 -0800 To: Kevin J Ma Cc: "cdni@ietf.org" Subject: Re: [CDNi] Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 06:59:58 -0000 > On Nov 5, 2013, at 8:54 PM, Kevin J Ma wrote: >=20 > I have a couple clarifying questions about the partial caching: >=20 > 1. Is there text somewhere that states that dCDNs MUST only cache what > the client requested? >=20 > Just because the dCDN is capable of partial caching, doesnt mean that > it won't go ahead and ask for the whole file? A uCDN (with a CSP customer with a very large video library) who is doing pa= rtial caching themselves needs their dCDNs to do something similar, and only= request content that users actually request (modulo some read ahead or what= ever). Otherwise, the dCDN's requests blow up the active library on the uCDN= 's caches, causing them to have to double storage capacity to cache portions= of the content no one is watching.=20 If a dCDN doesn't support the capability to only ask for what they need, the= uCDN may be better off serving the content themselves.=20 >=20 > 2. If we assume the dCDN only does partial acquisition requests, when > it receives a partial delivery request, then my question is, are > we concerned that dCDN is incapable of doing range requests? If > so, should that not show up in the acquisition protocol capability? >=20 > It's unclear to me what information the partial caching capability > is actually conveying? I'm not following. Range requests are how partial objects are transferred. I= f the dCDN doesn't support range requests, we have bigger problems.=20 >=20 > 3. If what we really want is a way for the uCDN to tell the dCDN whether > or not to use partial caching for a given piece of content, then I > would think what we need is a new metadata object, not a new capability?= I'm not familiar enough with the spec to know what we need there. But the ce= ntral requirement is for the uCDN to be able to tell dCDNs to do partial cac= hing for a given CSP's content, and for the uCDN to be able to avoid using a= ny dCDNs that don't support partial caching. -Scott >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] >> Sent: Tuesday, November 05, 2013 12:42 PM >> To: Kevin J Ma; Francois Le Faucheur (flefauch) >> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray); >> Larry Peterson; cdni@ietf.org; Daryl Malas >> Subject: RE: Discussing a "Partial Caching" Capability (for byte-range >> requests) in FCI semantics >>=20 >> Same here, we have not considered this, but sure let's discuss it during >> Thursday's lunch meeting >>=20 >> - Jan >>=20 >>> -----Original Message----- >>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>> Sent: Tuesday, November 05, 2013 5:16 PM >>> To: Francois Le Faucheur (flefauch); Jan Seedorf >>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray);= >>> Larry Peterson; cdni@ietf.org; Daryl Malas >>> Subject: RE: Discussing a "Partial Caching" Capability (for byte-range >>> requests) in FCI semantics >>>=20 >>> i did not consider it, but i am happy to discuss it. >>>=20 >>>=20 >>>=20 >>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >>> Sent: Tuesday, November 05, 2013 11:12 AM >>> To: Jan Seedorf; Kevin J Ma >>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg (Ray);= >>> Francois Le Faucheur (flefauch); Larry Peterson; cdni@ietf.org; Daryl >> Malas >>> Subject: Discussing a "Partial Caching" Capability (for byte-range >> requests) in >>> FCI semantics >>>=20 >>>=20 >>>=20 >>> Jan, Kevin, >>>=20 >>>=20 >>>=20 >>> Did you consider the following? >>>=20 >>> Can we discuss it in Vancouver? >>>=20 >>>=20 >>>=20 >>> Tx >>>=20 >>>=20 >>>=20 >>> On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) >>> wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Scott, Jan, and all, >>>=20 >>>=20 >>>=20 >>> On 15 Oct 2013, at 11:30, Scott Leibrand wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> This feature (partial object caching) is absolutely a requirement before= >> we >>> could think about offloading on-demand video traffic to a dCDN. If the >> dCDN >>> downloads the entire file, that completely ruins the uCDN's efforts to >> do >>> partial caching, and the resulting increase in cache use makes things >> worse >>> than not using a dCDN at all. >>>=20 >>>=20 >>>=20 >>> Then perhaps it would make sense to include something like "Partial >> Object >>> Caching" in the set of capabilities that can be advertised in the CDNI >> Footprint >>> and Capabilities Advertisement interface (FCI). This would allow the >> uCDN to >>> select a dCDN that supports partial object caching when required (or >> possibly >>> elect to serve itself). >>>=20 >>>=20 >>>=20 >>> Jan, >>>=20 >>> Would you mind including this as a candidate in your list so we rememebr= >> to >>> make a concious decision about it? >>>=20 >>>=20 >>>=20 >>> Thanks >>>=20 >>>=20 >>>=20 >>> Francois >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -Scott >>>=20 >>>=20 >>>=20 >>> On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van >>> wrote: >>>=20 >>> Hi Ben, >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >>>> Sent: maandag 14 oktober 2013 5:10 >>>> To: Brandenburg, R. (Ray) van >>>> Cc: cdni@ietf.org >>>> Subject: Re: [CDNi] CDNI and byte-range requests >>>>=20 >>>> Ray, >>>>=20 >>>>> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> As I'm not sure whether this should be part of the Redirection >> Interface >>>> document or the Framework document, let me just post this as a general >>>> question to the list: >>>>>=20 >>>>> To my knowledge, the current CDNI documents do not explicitly >> address >>>> the case of HTTP Byte-range requests. Although in most cases byte- >> range >>>> requests will function just as any other requests, I think there are >> some >>> cases >>>> where byte-range requests warrant further attention. An example is the >>>> Redirection interface. If a uCDN asks a dCDN to deliver a particular >> user >>>> request (containing a byte range), and the dCDN answers positively, >> can >>> the >>>> uCDN assume that the dCDN accepts any future requests for the same >> file >>>> with a different byte range? And if that is the case, is this default >> behavior >>> or >>>> do we need an explicit flag in the inter-CDN redirection request to >> indicate >>>> the uCDN/dCDN's preference? >>>>>=20 >>>>> To be clear: I don't think we need any new functionality to handle >> byte- >>>> range requests, but a few sentences in either the Framework or the RI >>>> document might clear up any future uncertainty. >>>>=20 >>>> I don't see how this is any different to a sequence of non byte-range >>>> requests. >>>>=20 >>>> It will likely depend on the behaviour of the client (and possibly >> whether >>> the >>>> server closes the connection after each request if that drives a >> different >>>> client behaviour) as to where the client ends up going (uCDN or dCDN) >>> when >>>> it makes a subsequent request. >>>>=20 >>>> Trying to say anything here may take us down the rat hole of trying to >>>> describe client behaviour which we don't control. >>>>=20 >>>=20 >>> Let me give a practical example: Let's say the uCDN is hosting a 2gb TS >> file. At >>> some point it receives an incoming request for a particular byte range >> within >>> that file, let's say the first 10mb. For some reason the uCDN decides >> that it >>> wants to redirect the request to a dCDN. The dCDN receives the request. >> At >>> that point it has to decide what to do: does it download the full 2gb >> file from >>> the uCDN, or does it download just the first 10mb? Of course it's fully >> up to >>> internal logic in the dCDN to decide what it should do here, however it >> does >>> have an impact on the uCDN as well (potentially unnecessary traffic >> reducing >>> the effectiveness of the inter-CDN redirect). My question is, do we need= >> to >>> say anything about this case to help both the dCDN and uCDN in making >> this >>> decision? >>>=20 >>> Ray >>>=20 >>>=20 >>>> Ben >>>>=20 >>>>>=20 >>>>> Best regards, >>>>>=20 >>>>> Ray >>>>> This e-mail and its contents are subject to the DISCLAIMER at >>>> http://www.tno.nl/emaildisclaimer >>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>>=20 >>>=20 >>>=20 >=20 From kevin.ma@azukisystems.com Wed Nov 6 07:43:05 2013 Return-Path: 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 38EA921E812A for ; Wed, 6 Nov 2013 07:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21BOcRrhcHXP for ; Wed, 6 Nov 2013 07:43:01 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0E43E21E8082 for ; Wed, 6 Nov 2013 07:42:59 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 38EF6416950; Wed, 6 Nov 2013 10:42:59 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 45F794168CE; Wed, 6 Nov 2013 10:42:58 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Wed, 6 Nov 2013 10:42:23 -0500 From: Kevin J Ma To: Scott Leibrand Date: Wed, 6 Nov 2013 10:42:52 -0500 Thread-Topic: Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics Thread-Index: Ac7avWA4UcbSpnaGQ++TkwmZ9Hxm3wAR8ulQ Message-ID: <291CC3F9E50E7641901A54E85D0977C6B027F5A648@MAILR002.mail.lan> References: <89B634B5-60FA-4AE7-A924-B76D86096CC6@cisco.com> <291CC3F9E50E7641901A54E85D0977C6B027F5A1A2@MAILR002.mail.lan> <2779C9F0771F974CAD742BAE6D9904FE639DAC05@PALLENE.office.hd> <291CC3F9E50E7641901A54E85D0977C6B027F5A550@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:43:05 -0000 Hi Scott, My point was that: wrt to 2), the dCDN can advertise its acquisition protocol capabilities. If it says it supports HTTP, it is assumed that it supports all of HTTP including range requests, so I see no reason to add an additional "Partial Caching" capability flag which essentially says: "yes I really do support range requests". If theres a dCDN that doesnt support range requests, then it should advertise some type of HTTP-lite for its acquisition protocol. That was a well debated use case for acquisition protocols, as I recall? wrt to 1) and 3), the uCDN telling the dCDN how to acquire content is a completely separate issue. It is really a metadata issue, not a capability issue (given that the capability part should already be addressed through the acqusition protocol capability). If what we are really looking for is a new HTTP-minus-range-gets protocol for the registry, and maybe a you-must-propogate-range-gets metadata, then that is a different discussion, and I would like to clarify that first? thanx. -- Kevin J. Ma > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand@llnw.com] > Sent: Wednesday, November 06, 2013 2:00 AM > To: Kevin J Ma > Cc: Jan Seedorf; Francois Le Faucheur (flefauch); Brandenburg, R. (Ray) > van; Larry Peterson; cdni@ietf.org; Daryl Malas > Subject: Re: Discussing a "Partial Caching" Capability (for byte-range > requests) in FCI semantics >=20 >=20 > > On Nov 5, 2013, at 8:54 PM, Kevin J Ma > wrote: > > > > I have a couple clarifying questions about the partial caching: > > > > 1. Is there text somewhere that states that dCDNs MUST only cache what > > the client requested? > > > > Just because the dCDN is capable of partial caching, doesnt mean that > > it won't go ahead and ask for the whole file? >=20 > A uCDN (with a CSP customer with a very large video library) who is doing > partial caching themselves needs their dCDNs to do something similar, and > only request content that users actually request (modulo some read ahead > or whatever). Otherwise, the dCDN's requests blow up the active library o= n > the uCDN's caches, causing them to have to double storage capacity to > cache portions of the content no one is watching. >=20 > If a dCDN doesn't support the capability to only ask for what they need, > the uCDN may be better off serving the content themselves. >=20 > > > > 2. If we assume the dCDN only does partial acquisition requests, when > > it receives a partial delivery request, then my question is, are > > we concerned that dCDN is incapable of doing range requests? If > > so, should that not show up in the acquisition protocol capability? > > > > It's unclear to me what information the partial caching capability > > is actually conveying? >=20 > I'm not following. Range requests are how partial objects are transferred= . > If the dCDN doesn't support range requests, we have bigger problems. >=20 > > > > 3. If what we really want is a way for the uCDN to tell the dCDN whethe= r > > or not to use partial caching for a given piece of content, then I > > would think what we need is a new metadata object, not a new > capability? >=20 > I'm not familiar enough with the spec to know what we need there. But the > central requirement is for the uCDN to be able to tell dCDNs to do partia= l > caching for a given CSP's content, and for the uCDN to be able to avoid > using any dCDNs that don't support partial caching. >=20 > -Scott > > > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] > >> Sent: Tuesday, November 05, 2013 12:42 PM > >> To: Kevin J Ma; Francois Le Faucheur (flefauch) > >> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg > (Ray); > >> Larry Peterson; cdni@ietf.org; Daryl Malas > >> Subject: RE: Discussing a "Partial Caching" Capability (for byte-range > >> requests) in FCI semantics > >> > >> Same here, we have not considered this, but sure let's discuss it > during > >> Thursday's lunch meeting > >> > >> - Jan > >> > >>> -----Original Message----- > >>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > >>> Sent: Tuesday, November 05, 2013 5:16 PM > >>> To: Francois Le Faucheur (flefauch); Jan Seedorf > >>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg > (Ray); > >>> Larry Peterson; cdni@ietf.org; Daryl Malas > >>> Subject: RE: Discussing a "Partial Caching" Capability (for byte-rang= e > >>> requests) in FCI semantics > >>> > >>> i did not consider it, but i am happy to discuss it. > >>> > >>> > >>> > >>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > >>> Sent: Tuesday, November 05, 2013 11:12 AM > >>> To: Jan Seedorf; Kevin J Ma > >>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg > (Ray); > >>> Francois Le Faucheur (flefauch); Larry Peterson; cdni@ietf.org; Daryl > >> Malas > >>> Subject: Discussing a "Partial Caching" Capability (for byte-range > >> requests) in > >>> FCI semantics > >>> > >>> > >>> > >>> Jan, Kevin, > >>> > >>> > >>> > >>> Did you consider the following? > >>> > >>> Can we discuss it in Vancouver? > >>> > >>> > >>> > >>> Tx > >>> > >>> > >>> > >>> On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) > >>> wrote: > >>> > >>> > >>> > >>> > >>> > >>> Scott, Jan, and all, > >>> > >>> > >>> > >>> On 15 Oct 2013, at 11:30, Scott Leibrand wrote: > >>> > >>> > >>> > >>> > >>> > >>> This feature (partial object caching) is absolutely a requirement > before > >> we > >>> could think about offloading on-demand video traffic to a dCDN. If > the > >> dCDN > >>> downloads the entire file, that completely ruins the uCDN's efforts t= o > >> do > >>> partial caching, and the resulting increase in cache use makes things > >> worse > >>> than not using a dCDN at all. > >>> > >>> > >>> > >>> Then perhaps it would make sense to include something like "Partial > >> Object > >>> Caching" in the set of capabilities that can be advertised in the CDN= I > >> Footprint > >>> and Capabilities Advertisement interface (FCI). This would allow the > >> uCDN to > >>> select a dCDN that supports partial object caching when required (or > >> possibly > >>> elect to serve itself). > >>> > >>> > >>> > >>> Jan, > >>> > >>> Would you mind including this as a candidate in your list so we > rememebr > >> to > >>> make a concious decision about it? > >>> > >>> > >>> > >>> Thanks > >>> > >>> > >>> > >>> Francois > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -Scott > >>> > >>> > >>> > >>> On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van > >>> wrote: > >>> > >>> Hi Ben, > >>> > >>> > >>>> -----Original Message----- > >>>> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > >>>> Sent: maandag 14 oktober 2013 5:10 > >>>> To: Brandenburg, R. (Ray) van > >>>> Cc: cdni@ietf.org > >>>> Subject: Re: [CDNi] CDNI and byte-range requests > >>>> > >>>> Ray, > >>>> > >>>>> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> As I'm not sure whether this should be part of the Redirection > >> Interface > >>>> document or the Framework document, let me just post this as a > general > >>>> question to the list: > >>>>> > >>>>> To my knowledge, the current CDNI documents do not explicitly > >> address > >>>> the case of HTTP Byte-range requests. Although in most cases byte- > >> range > >>>> requests will function just as any other requests, I think there are > >> some > >>> cases > >>>> where byte-range requests warrant further attention. An example is > the > >>>> Redirection interface. If a uCDN asks a dCDN to deliver a particular > >> user > >>>> request (containing a byte range), and the dCDN answers positively, > >> can > >>> the > >>>> uCDN assume that the dCDN accepts any future requests for the same > >> file > >>>> with a different byte range? And if that is the case, is this defaul= t > >> behavior > >>> or > >>>> do we need an explicit flag in the inter-CDN redirection request to > >> indicate > >>>> the uCDN/dCDN's preference? > >>>>> > >>>>> To be clear: I don't think we need any new functionality to handle > >> byte- > >>>> range requests, but a few sentences in either the Framework or the R= I > >>>> document might clear up any future uncertainty. > >>>> > >>>> I don't see how this is any different to a sequence of non byte-rang= e > >>>> requests. > >>>> > >>>> It will likely depend on the behaviour of the client (and possibly > >> whether > >>> the > >>>> server closes the connection after each request if that drives a > >> different > >>>> client behaviour) as to where the client ends up going (uCDN or dCDN= ) > >>> when > >>>> it makes a subsequent request. > >>>> > >>>> Trying to say anything here may take us down the rat hole of trying > to > >>>> describe client behaviour which we don't control. > >>>> > >>> > >>> Let me give a practical example: Let's say the uCDN is hosting a 2gb > TS > >> file. At > >>> some point it receives an incoming request for a particular byte rang= e > >> within > >>> that file, let's say the first 10mb. For some reason the uCDN decides > >> that it > >>> wants to redirect the request to a dCDN. The dCDN receives the > request. > >> At > >>> that point it has to decide what to do: does it download the full 2gb > >> file from > >>> the uCDN, or does it download just the first 10mb? Of course it's > fully > >> up to > >>> internal logic in the dCDN to decide what it should do here, however > it > >> does > >>> have an impact on the uCDN as well (potentially unnecessary traffic > >> reducing > >>> the effectiveness of the inter-CDN redirect). My question is, do we > need > >> to > >>> say anything about this case to help both the dCDN and uCDN in making > >> this > >>> decision? > >>> > >>> Ray > >>> > >>> > >>>> Ben > >>>> > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Ray > >>>>> This e-mail and its contents are subject to the DISCLAIMER at > >>>> http://www.tno.nl/emaildisclaimer > >>>>> > >>>>> _______________________________________________ > >>>>> CDNi mailing list > >>>>> CDNi@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/cdni > >>> > >>> _______________________________________________ > >>> CDNi mailing list > >>> CDNi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cdni > >>> > >>> > >>> > >>> _______________________________________________ > >>> CDNi mailing list > >>> CDNi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cdni > >>> > >>> > >>> > >>> > > From ray.vanbrandenburg@tno.nl Thu Nov 7 11:50:27 2013 Return-Path: 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 B026B11E822F for ; Thu, 7 Nov 2013 11:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01Jdt+GeVhA3 for ; Thu, 7 Nov 2013 11:50:23 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1C811E8188 for ; Thu, 7 Nov 2013 11:50:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,653,1378850400"; d="scan'208";a="2632348" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 07 Nov 2013 20:50:15 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.174]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 20:50:15 +0100 From: "Brandenburg, R. (Ray) van" To: Kevin J Ma Thread-Topic: Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics Thread-Index: AQHO2kHaEoydmce4Xk68ta76rKTpxJoWv1KAgAAYH4CAALvQAIAAIwmAgACSIwCAAeg2ww== Date: Thu, 7 Nov 2013 19:50:14 +0000 Message-ID: <3204FE67-6E32-42ED-AC02-CA45B544F9C5@tno.nl> References: <89B634B5-60FA-4AE7-A924-B76D86096CC6@cisco.com> <291CC3F9E50E7641901A54E85D0977C6B027F5A1A2@MAILR002.mail.lan> <2779C9F0771F974CAD742BAE6D9904FE639DAC05@PALLENE.office.hd> <291CC3F9E50E7641901A54E85D0977C6B027F5A550@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B027F5A648@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B027F5A648@MAILR002.mail.lan> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "cdni@ietf.org" Subject: Re: [CDNi] Discussing a "Partial Caching" Capability (for byte-range requests) in FCI semantics 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 19:50:27 -0000 Hi all, I think Kevin raises an interesting point. It's not so much a capability th= at you want to check for, it's something you want to mandate from a dCDN, s= imilar to how a uCDN might mandate other elements of the delivery process. = In that sense, the metadata interface is indeed a more appropriate interfac= e. = (Now that we're discussing this, do we have to worry about people arguing t= hat mandating something that has to do with acquisition goes against the ch= arter which specifies the acquisition interface to be out of scope? :)) Best regards, Ray > On 6 nov. 2013, at 16:43, "Kevin J Ma" wrote: > = > Hi Scott, > = > My point was that: > = > wrt to 2), the dCDN can advertise its acquisition protocol capabilities. > If it says it supports HTTP, it is assumed that it supports all of HTTP > including range requests, so I see no reason to add an additional > "Partial Caching" capability flag which essentially says: "yes I really > do support range requests". If theres a dCDN that doesnt support range > requests, then it should advertise some type of HTTP-lite for its > acquisition protocol. That was a well debated use case for acquisition > protocols, as I recall? > = > wrt to 1) and 3), the uCDN telling the dCDN how to acquire content is > a completely separate issue. It is really a metadata issue, not a > capability issue (given that the capability part should already be > addressed through the acqusition protocol capability). > = > If what we are really looking for is a new HTTP-minus-range-gets > protocol for the registry, and maybe a you-must-propogate-range-gets > metadata, then that is a different discussion, and I would like to > clarify that first? > = > thanx. > = > -- Kevin J. Ma > = >> -----Original Message----- >> From: Scott Leibrand [mailto:sleibrand@llnw.com] >> Sent: Wednesday, November 06, 2013 2:00 AM >> To: Kevin J Ma >> Cc: Jan Seedorf; Francois Le Faucheur (flefauch); Brandenburg, R. (Ray) >> van; Larry Peterson; cdni@ietf.org; Daryl Malas >> Subject: Re: Discussing a "Partial Caching" Capability (for byte-range >> requests) in FCI semantics >> = >> = >>>> On Nov 5, 2013, at 8:54 PM, Kevin J Ma >>> wrote: >>> = >>> I have a couple clarifying questions about the partial caching: >>> = >>> 1. Is there text somewhere that states that dCDNs MUST only cache what >>> the client requested? >>> = >>> Just because the dCDN is capable of partial caching, doesnt mean that >>> it won't go ahead and ask for the whole file? >> = >> A uCDN (with a CSP customer with a very large video library) who is doing >> partial caching themselves needs their dCDNs to do something similar, and >> only request content that users actually request (modulo some read ahead >> or whatever). Otherwise, the dCDN's requests blow up the active library = on >> the uCDN's caches, causing them to have to double storage capacity to >> cache portions of the content no one is watching. >> = >> If a dCDN doesn't support the capability to only ask for what they need, >> the uCDN may be better off serving the content themselves. >> = >>> = >>> 2. If we assume the dCDN only does partial acquisition requests, when >>> it receives a partial delivery request, then my question is, are >>> we concerned that dCDN is incapable of doing range requests? If >>> so, should that not show up in the acquisition protocol capability? >>> = >>> It's unclear to me what information the partial caching capability >>> is actually conveying? >> = >> I'm not following. Range requests are how partial objects are transferre= d. >> If the dCDN doesn't support range requests, we have bigger problems. >> = >>> = >>> 3. If what we really want is a way for the uCDN to tell the dCDN whether >>> or not to use partial caching for a given piece of content, then I >>> would think what we need is a new metadata object, not a new >> capability? >> = >> I'm not familiar enough with the spec to know what we need there. But the >> central requirement is for the uCDN to be able to tell dCDNs to do parti= al >> caching for a given CSP's content, and for the uCDN to be able to avoid >> using any dCDNs that don't support partial caching. >> = >> -Scott >>> = >>> thanx. >>> = >>> -- Kevin J. Ma >>> = >>>> -----Original Message----- >>>> From: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] >>>> Sent: Tuesday, November 05, 2013 12:42 PM >>>> To: Kevin J Ma; Francois Le Faucheur (flefauch) >>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg >> (Ray); >>>> Larry Peterson; cdni@ietf.org; Daryl Malas >>>> Subject: RE: Discussing a "Partial Caching" Capability (for byte-range >>>> requests) in FCI semantics >>>> = >>>> Same here, we have not considered this, but sure let's discuss it >> during >>>> Thursday's lunch meeting >>>> = >>>> - Jan >>>> = >>>>> -----Original Message----- >>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>> Sent: Tuesday, November 05, 2013 5:16 PM >>>>> To: Francois Le Faucheur (flefauch); Jan Seedorf >>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg >> (Ray); >>>>> Larry Peterson; cdni@ietf.org; Daryl Malas >>>>> Subject: RE: Discussing a "Partial Caching" Capability (for byte-range >>>>> requests) in FCI semantics >>>>> = >>>>> i did not consider it, but i am happy to discuss it. >>>>> = >>>>> = >>>>> = >>>>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >>>>> Sent: Tuesday, November 05, 2013 11:12 AM >>>>> To: Jan Seedorf; Kevin J Ma >>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg >> (Ray); >>>>> Francois Le Faucheur (flefauch); Larry Peterson; cdni@ietf.org; Daryl >>>> Malas >>>>> Subject: Discussing a "Partial Caching" Capability (for byte-range >>>> requests) in >>>>> FCI semantics >>>>> = >>>>> = >>>>> = >>>>> Jan, Kevin, >>>>> = >>>>> = >>>>> = >>>>> Did you consider the following? >>>>> = >>>>> Can we discuss it in Vancouver? >>>>> = >>>>> = >>>>> = >>>>> Tx >>>>> = >>>>> = >>>>> = >>>>> On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) >>>>> wrote: >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> Scott, Jan, and all, >>>>> = >>>>> = >>>>> = >>>>> On 15 Oct 2013, at 11:30, Scott Leibrand wrote: >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> This feature (partial object caching) is absolutely a requirement >> before >>>> we >>>>> could think about offloading on-demand video traffic to a dCDN. If >> the >>>> dCDN >>>>> downloads the entire file, that completely ruins the uCDN's efforts to >>>> do >>>>> partial caching, and the resulting increase in cache use makes things >>>> worse >>>>> than not using a dCDN at all. >>>>> = >>>>> = >>>>> = >>>>> Then perhaps it would make sense to include something like "Partial >>>> Object >>>>> Caching" in the set of capabilities that can be advertised in the CDNI >>>> Footprint >>>>> and Capabilities Advertisement interface (FCI). This would allow the >>>> uCDN to >>>>> select a dCDN that supports partial object caching when required (or >>>> possibly >>>>> elect to serve itself). >>>>> = >>>>> = >>>>> = >>>>> Jan, >>>>> = >>>>> Would you mind including this as a candidate in your list so we >> rememebr >>>> to >>>>> make a concious decision about it? >>>>> = >>>>> = >>>>> = >>>>> Thanks >>>>> = >>>>> = >>>>> = >>>>> Francois >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> -Scott >>>>> = >>>>> = >>>>> = >>>>> On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van >>>>> wrote: >>>>> = >>>>> Hi Ben, >>>>> = >>>>> = >>>>>> -----Original Message----- >>>>>> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >>>>>> Sent: maandag 14 oktober 2013 5:10 >>>>>> To: Brandenburg, R. (Ray) van >>>>>> Cc: cdni@ietf.org >>>>>> Subject: Re: [CDNi] CDNI and byte-range requests >>>>>> = >>>>>> Ray, >>>>>> = >>>>>>> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: >>>>>>> = >>>>>>> Hi all, >>>>>>> = >>>>>>> As I'm not sure whether this should be part of the Redirection >>>> Interface >>>>>> document or the Framework document, let me just post this as a >> general >>>>>> question to the list: >>>>>>> = >>>>>>> To my knowledge, the current CDNI documents do not explicitly >>>> address >>>>>> the case of HTTP Byte-range requests. Although in most cases byte- >>>> range >>>>>> requests will function just as any other requests, I think there are >>>> some >>>>> cases >>>>>> where byte-range requests warrant further attention. An example is >> the >>>>>> Redirection interface. If a uCDN asks a dCDN to deliver a particular >>>> user >>>>>> request (containing a byte range), and the dCDN answers positively, >>>> can >>>>> the >>>>>> uCDN assume that the dCDN accepts any future requests for the same >>>> file >>>>>> with a different byte range? And if that is the case, is this default >>>> behavior >>>>> or >>>>>> do we need an explicit flag in the inter-CDN redirection request to >>>> indicate >>>>>> the uCDN/dCDN's preference? >>>>>>> = >>>>>>> To be clear: I don't think we need any new functionality to handle >>>> byte- >>>>>> range requests, but a few sentences in either the Framework or the RI >>>>>> document might clear up any future uncertainty. >>>>>> = >>>>>> I don't see how this is any different to a sequence of non byte-range >>>>>> requests. >>>>>> = >>>>>> It will likely depend on the behaviour of the client (and possibly >>>> whether >>>>> the >>>>>> server closes the connection after each request if that drives a >>>> different >>>>>> client behaviour) as to where the client ends up going (uCDN or dCDN) >>>>> when >>>>>> it makes a subsequent request. >>>>>> = >>>>>> Trying to say anything here may take us down the rat hole of trying >> to >>>>>> describe client behaviour which we don't control. >>>>> = >>>>> Let me give a practical example: Let's say the uCDN is hosting a 2gb >> TS >>>> file. At >>>>> some point it receives an incoming request for a particular byte range >>>> within >>>>> that file, let's say the first 10mb. For some reason the uCDN decides >>>> that it >>>>> wants to redirect the request to a dCDN. The dCDN receives the >> request. >>>> At >>>>> that point it has to decide what to do: does it download the full 2gb >>>> file from >>>>> the uCDN, or does it download just the first 10mb? Of course it's >> fully >>>> up to >>>>> internal logic in the dCDN to decide what it should do here, however >> it >>>> does >>>>> have an impact on the uCDN as well (potentially unnecessary traffic >>>> reducing >>>>> the effectiveness of the inter-CDN redirect). My question is, do we >> need >>>> to >>>>> say anything about this case to help both the dCDN and uCDN in making >>>> this >>>>> decision? >>>>> = >>>>> Ray >>>>> = >>>>> = >>>>>> Ben >>>>>> = >>>>>>> = >>>>>>> Best regards, >>>>>>> = >>>>>>> Ray >>>>>>> This e-mail and its contents are subject to the DISCLAIMER at >>>>>> http://www.tno.nl/emaildisclaimer >>>>>>> = >>>>>>> _______________________________________________ >>>>>>> CDNi mailing list >>>>>>> CDNi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>> = >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>> = >>>>> = >>>>> = >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>> = Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From Jan.Seedorf@neclab.eu Thu Nov 7 16:45:13 2013 Return-Path: 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 851C921E8124 for ; Thu, 7 Nov 2013 16:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.509 X-Spam-Level: X-Spam-Status: No, score=-103.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNkQW7XIM7ea for ; Thu, 7 Nov 2013 16:45:08 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id BC85321E80B7 for ; Thu, 7 Nov 2013 16:44:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id EC53F105F6E; Fri, 8 Nov 2013 01:38:07 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdkW8c5CjtWT; Fri, 8 Nov 2013 01:38:07 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id C8401105F6F; Fri, 8 Nov 2013 01:37:37 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.11]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 8 Nov 2013 01:43:55 +0100 From: Jan Seedorf To: "Francois Le Faucheur (flefauch)" Thread-Topic: Optional Capabilities for CDNI Logging Thread-Index: AQHOu4WIt+wdrb2ytUK2MiwOvtuVsJoavbaQ Date: Fri, 8 Nov 2013 00:43:55 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE639DEEFE@PALLENE.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE55604B98@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE55605381@DAPHNIS.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Optional Capabilities for CDNI Logging 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:45:13 -0000 This is the email about logging capabilities I just referred to at the mic = in the CDNI session at IETF-88. I guess we need to discuss this more. - Jan > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Friday, September 27, 2013 3:29 PM > To: Jan Seedorf > Cc: cdni@ietf.org; Peterson, Jon (jon.peterson@neustar.biz); Kevin J Ma > (kevin.ma@azukisystems.com); Brandenburg, R. (Ray) van > (ray.vanbrandenburg@tno.nl); Stefano Previdi (sprevidi) > Subject: Optional Capabilities for CDNI Logging >=20 > Jan and all, >=20 > [as a cdni-logging co-author] >=20 > I think we (cdni-logging authors) had an action item to identify the opti= onal > capabilities of a dCDN related to CDNI Logging. >=20 > There are currently three such optional capabilities: > * support of anonymization and of the c-ip-anonimizing Logging Field > * support for Content Collection IDentifier (CCID) and of the s-ccid > Logging Field > * support for Session IDentifier (SID) and of the s-sid Logging Field >=20 > Support for all the other Logging Fields and associated finctioanlity is > mandatory in the sense that it must be supported by implementations. >=20 > Please make sure these are covered/registered as appropriate in the FCI > work. >=20 > Thank you. >=20 > Francois >=20 >=20 >=20 From flefauch@cisco.com Thu Nov 7 16:49:04 2013 Return-Path: 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 46F0A11E80E2 for ; Thu, 7 Nov 2013 16:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRGp3V-wQzyL for ; Thu, 7 Nov 2013 16:48:58 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 92ED311E8125 for ; Thu, 7 Nov 2013 16:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1699; q=dns/txt; s=iport; t=1383871738; x=1385081338; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oLLNbm/10XJOM5pkjItRRbrHHl3N9DH1PrrFId8NMFw=; b=DjmmiNyzSxjk5IlQiIfMw0RQUUkxjiN0am0GmFADEKkDeXdr4tOeAtG0 XGOt9LI8H3YNgN5rwBocVIdVUNpczCed4PxiFZziRYYpjSSXCmFnW0RUs 7Xvp12haq3P93Y+Bs8Al0JFb1XvnS78zbrRuoxULQdgiDFzlS2aaPsLKW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAF80fFKtJXG//2dsb2JhbABQCoMHgQu/EIEoFnSCJQEBAQMBOj8FBwQCAQgRBAEBHwkHMhQJCAIEDgWHewa9R44QBoEQCCsHAgSDGoEQA5gMkgqDJoFxOQ X-IronPort-AV: E=Sophos;i="4.93,655,1378857600"; d="scan'208";a="282250143" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 08 Nov 2013 00:48:58 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA80mvpA017876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 00:48:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 18:48:57 -0600 From: "Francois Le Faucheur (flefauch)" To: Jan Seedorf Thread-Topic: Optional Capabilities for CDNI Logging Thread-Index: AQHOu4WIt+wdrb2ytUK2MiwOvtuVsJoavbaQgABocoA= Date: Fri, 8 Nov 2013 00:48:57 +0000 Message-ID: <974C1D9E-EB3E-411A-8156-F10DD3CEE2D7@cisco.com> References: <2779C9F0771F974CAD742BAE6D9904FE55604B98@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE55605381@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE639DEEFE@PALLENE.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE639DEEFE@PALLENE.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.96.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <70E2AE3D9BB3AF48952862FE7FEC95D9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Optional Capabilities for CDNI Logging 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:49:04 -0000 Right. I remember the message. It does say there are three optional capbili= ties, but it does not say anything about mandatory capabilities.=20 We should discuss what information you need about that. On 7 Nov 2013, at 16:43, Jan Seedorf wrote: > This is the email about logging capabilities I just referred to at the mi= c in the CDNI session at IETF-88. I guess we need to discuss this more. >=20 > - Jan >=20 >> -----Original Message----- >> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >> Sent: Friday, September 27, 2013 3:29 PM >> To: Jan Seedorf >> Cc: cdni@ietf.org; Peterson, Jon (jon.peterson@neustar.biz); Kevin J Ma >> (kevin.ma@azukisystems.com); Brandenburg, R. (Ray) van >> (ray.vanbrandenburg@tno.nl); Stefano Previdi (sprevidi) >> Subject: Optional Capabilities for CDNI Logging >>=20 >> Jan and all, >>=20 >> [as a cdni-logging co-author] >>=20 >> I think we (cdni-logging authors) had an action item to identify the opt= ional >> capabilities of a dCDN related to CDNI Logging. >>=20 >> There are currently three such optional capabilities: >> * support of anonymization and of the c-ip-anonimizing Logging Field >> * support for Content Collection IDentifier (CCID) and of the s-ccid >> Logging Field >> * support for Session IDentifier (SID) and of the s-sid Logging Field >>=20 >> Support for all the other Logging Fields and associated finctioanlity is >> mandatory in the sense that it must be supported by implementations. >>=20 >> Please make sure these are covered/registered as appropriate in the FCI >> work. >>=20 >> Thank you. >>=20 >> Francois >>=20 >>=20 >>=20 >=20 From kleung@cisco.com Thu Nov 7 23:50:00 2013 Return-Path: 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 9E62111E8218 for ; Thu, 7 Nov 2013 23:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bftyrXR4LEuV for ; Thu, 7 Nov 2013 23:49:55 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 04EB711E81D3 for ; Thu, 7 Nov 2013 23:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4312; q=dns/txt; s=iport; t=1383896995; x=1385106595; h=from:to:subject:date:message-id:mime-version; bh=o8+nwWsmboxpAm/WKXNR8xNcD5HJc4Fp0Ih3XPM8W74=; b=QPIJU4UW/Wr9h+VJz0V11KZ/fyI6/I5yKjoEQOgyIaFj9IIq15xR0KRW 9f1DGvuEmChf1WOOWpoDp67WwGEwzVbI3ON9vR4iZK3vj0KeJIHCMF8CH hl9Z6xSDQ6BuHEl/v7rbeqcoDALIgQQfvEXbAcdEbPuTIZ+9q2+R2i/bD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMGAD+XfFKtJXHA/2dsb2JhbABagkNEOFO/FIEtFm0HgicBBC1eAQweViYBBBsTh2abRqFWjzaDWIEQA6oagyaBaiQc X-IronPort-AV: E=Sophos;i="4.93,658,1378857600"; d="scan'208,217";a="282340213" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 08 Nov 2013 07:49:54 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA87nsiT001166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Nov 2013 07:49:54 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 01:49:53 -0600 From: "Kent Leung (kleung)" To: "cdni@ietf.org" Thread-Topic: URI structure issue with draft-leung-cdni-uri-signing-03 Thread-Index: Ac7cVxkp2B429Y2iTw+ZtXmQWSPwww== Date: Fri, 8 Nov 2013 07:49:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.97.252] Content-Type: multipart/alternative; boundary="_000_CD85F32117029D4F9AEF48BDEF5536AB1DB8A6D1xmbalnx03ciscoc_" MIME-Version: 1.0 Subject: [CDNi] URI structure issue with draft-leung-cdni-uri-signing-03 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 07:50:00 -0000 --_000_CD85F32117029D4F9AEF48BDEF5536AB1DB8A6D1xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just an update on this topic. A few of us met with Mark Nottingham today to discuss the issue that he bro= ught up in draft-nottingham-uri-get-off-my-lawn. In summary, Mark does not = want "baked in" query string attributes or any portion in the URI. So, the = proposed solution presented in the WG session should address that concern. = Basically, CDNI metadata conveys how the query string is encoded to include= the URI Signing information elements (URI signature, algorithm used, etc.)= This information is used by the Downstream CDN to validate the Signed URI. The next step is to revise the draft so the URI Signing method uses this ap= proach. It should also incorporate the comments from Kevin. When that's rea= dy, Mark agreed to review the draft and stamp it as "off his lawn" if the s= olution no longer is standardizing a structure in the URI. :) Kent --_000_CD85F32117029D4F9AEF48BDEF5536AB1DB8A6D1xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just an update on this topic.

 

A few of us met with Mark Nottingham today to discus= s the issue that he brought up in draft-nottingham-uri-get-off-my-lawn. In = summary, Mark does not want “baked in” query string attributes = or any portion in the URI. So, the proposed solution presented in the WG session should address that concern. Basically, CDNI m= etadata conveys how the query string is encoded to include the URI Signing = information elements (URI signature, algorithm used, etc.) This information= is used by the Downstream CDN to validate the Signed URI.

 

The next step is to revise the draft so the URI Sign= ing method uses this approach. It should also incorporate the comments from= Kevin. When that’s ready, Mark agreed to review the draft and stamp = it as “off his lawn” if the solution no longer is standardizing a structure in the URI. J

 

Kent

 

 

--_000_CD85F32117029D4F9AEF48BDEF5536AB1DB8A6D1xmbalnx03ciscoc_-- From flefauch@cisco.com Fri Nov 8 10:50:58 2013 Return-Path: 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 D788411E8110 for ; Fri, 8 Nov 2013 10:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUZaxkri5Pj5 for ; Fri, 8 Nov 2013 10:50:44 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D8B7F21F9FDA for ; Fri, 8 Nov 2013 10:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5136; q=dns/txt; s=iport; t=1383936642; x=1385146242; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KjVTqpS6i1iG6zV02rTOf7r/jVZLhVAul1K5woXp6EA=; b=dXmVWDpb7QJxiQjR63E4MiObW4FT+wol/j/HZyagGUFJrrNTGTYQ08HB r+2cx1mxwpekv3T5zsMXv/fvn68sC2dt145Q+IyRPkxkgS5W3FQWrXLd0 jDq4Jy0iOqlFaLpBwE1VRkJvoBJY9kOaX/06Z7XS20n9y2810FeFKVOik E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAO8xfVKtJXG8/2dsb2JhbABZgkNEOFO/FoEwFnSCJgEBBAEBAWsLEAIBCD8HJwsUEQEBBAENBRuHZg29KASPYwQHgyCBEAOYD5ILgyaBaiQc X-IronPort-AV: E=Sophos;i="4.93,661,1378857600"; d="scan'208,217";a="282561329" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 08 Nov 2013 18:50:41 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA8Iofjc017811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 18:50:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 12:50:41 -0600 From: "Francois Le Faucheur (flefauch)" To: "Kent Leung (kleung)" , Mark Nottingham Thread-Topic: [CDNi] URI structure issue with draft-leung-cdni-uri-signing-03 Thread-Index: Ac7cVxkp2B429Y2iTw+ZtXmQWSPwwwAjp16A Date: Fri, 8 Nov 2013 18:50:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.59] Content-Type: multipart/alternative; boundary="_000_E91F0E52E262473189D0F63F18776E5Dciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] URI structure issue with draft-leung-cdni-uri-signing-03 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 18:50:59 -0000 --_000_E91F0E52E262473189D0F63F18776E5Dciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Putting Mark explicitely in the loop. Francois On 7 Nov 2013, at 23:49, Kent Leung (kleung) > wrote: Just an update on this topic. A few of us met with Mark Nottingham today to discuss the issue that he bro= ught up in draft-nottingham-uri-get-off-my-lawn. In summary, Mark does not = want =93baked in=94 query string attributes or any portion in the URI. So, = the proposed solution presented in the WG session should address that conce= rn. Basically, CDNI metadata conveys how the query string is encoded to inc= lude the URI Signing information elements (URI signature, algorithm used, e= tc.) This information is used by the Downstream CDN to validate the Signed = URI. The next step is to revise the draft so the URI Signing method uses this ap= proach. It should also incorporate the comments from Kevin. When that=92s r= eady, Mark agreed to review the draft and stamp it as =93off his lawn=94 if= the solution no longer is standardizing a structure in the URI. :) Kent _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_E91F0E52E262473189D0F63F18776E5Dciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Putting Mark explicitely in the loop.
Francois

On 7 Nov 2013, at 23:49, Kent Leung (kleung) <kleung@cisco.com> wrote:

Just an update on this topic.
 
A few of us met with Mark Nottingham today to discuss the issue that he bro= ught up in draft-nottingham-uri-get-off-my-lawn. In summary, Mark does not = want =93baked in=94 query string attributes or any portion in the URI. So, = the proposed solution presented in the WG session should address that concern. Basically, CDNI metadata conveys h= ow the query string is encoded to include the URI Signing information eleme= nts (URI signature, algorithm used, etc.) This information is used by the D= ownstream CDN to validate the Signed URI.
 
The next step is to revise the draft so the URI Signing method uses this ap= proach. It should also incorporate the comments from Kevin. When that=92s r= eady, Mark agreed to review the draft and stamp it as =93off his lawn=94 if= the solution no longer is standardizing a structure in the URI. = J
 
Kent
 
 
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdn= i

--_000_E91F0E52E262473189D0F63F18776E5Dciscocom_-- From flefauch@cisco.com Fri Nov 8 17:33:05 2013 Return-Path: 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 4186921E8099 for ; Fri, 8 Nov 2013 17:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oICXzMmA1Kd for ; Fri, 8 Nov 2013 17:33:00 -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 49D0621E8087 for ; Fri, 8 Nov 2013 17:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14979; q=dns/txt; s=iport; t=1383960780; x=1385170380; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jxluJSkYRMwBxc5j/IgPTQimjNeRUeda5wYnA49zXvY=; b=LAjb0qVKVYSeofwPXzHSfAM89DSwZxDWg9BXh1c13Pz0o9R7s5pTfwyw CwY6s+3hf7J+ZbDE1haEMMdkP/tlpnLsEzk1OuRZCi8P5STyfP1gNIteS DzBrximRQwImBPaK1iNY3c3uCOhdsV+xeQG7m6YTVfpaOWnPmYKxaO47s 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAH6PfVKtJV2c/2dsb2JhbABZgwc4U78VgTAWdIIlAQEBAwEBAQE3NAsFBwQCARkEAQEBHgkHJwsUCQgCBAoEBYd7Bg29Fo4uBoEzBwaDGoEQA5gPkguDJoFpCBci X-IronPort-AV: E=Sophos;i="4.93,664,1378857600"; d="scan'208";a="282677535" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 09 Nov 2013 01:32:59 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA91WwFA028160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Nov 2013 01:32:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Fri, 8 Nov 2013 19:32:58 -0600 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: Suggestion for progressing on "Partial Caching"/"Byte Range request" Thread-Index: AQHO3Oueq11Hv0EDx0KlPyqtovgQKg== Date: Sat, 9 Nov 2013 01:32:58 +0000 Message-ID: <6C0BCBC2-19CA-4C80-9657-DCE062835BA2@cisco.com> References: <89B634B5-60FA-4AE7-A924-B76D86096CC6@cisco.com> <291CC3F9E50E7641901A54E85D0977C6B027F5A1A2@MAILR002.mail.lan> <2779C9F0771F974CAD742BAE6D9904FE639DAC05@PALLENE.office.hd> <291CC3F9E50E7641901A54E85D0977C6B027F5A550@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B027F5A648@MAILR002.mail.lan> <3204FE67-6E32-42ED-AC02-CA45B544F9C5@tno.nl> In-Reply-To: <3204FE67-6E32-42ED-AC02-CA45B544F9C5@tno.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.210.82] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Suggestion for progressing on "Partial Caching"/"Byte Range request" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 01:33:05 -0000 Hi Ray and all, Based on a few conversations here in Vancouver on that topic, I think handl= ing of Partial Caching in CDNI would involve: * defining a Capability, so the dCDN can indicate in FCI whether/how it su= pports "Partial Caching" (e.g. dCDN does not support Partial Caching, dCDN = support Partial Caching for all content, dCDN supports Partial Caching on a= per content item/set basis) * defining an additional CDNI Metadata information Element, allowing the u= CDN to tell the dCDN (or a per content item/content sets basis) whether "pa= rtial Caching" is needed (or not) from dCDN when client issues a byte range= request to this content. Something like: o Partial-Caching: dCDN needs to minimise the amount of data requested o= n acquisition - eg by only acquiring the same byte range as requested by en= d-user,=20 o No-Partial-Caching: dCDN is not required to minimise the amount of data= requested on acquisition - ie dCDN behaves whichever way it wants. A possible way to progress this would be to take a similar approach to what= is being done for rate-pacing, ie progress a standalone I-D that focuses o= n this functionality and defines the corresponding use case + overall funct= ionality, and defines the impact and necessary extensions for each of the C= DNI interfaces. Makes sense? Would you be interested in driving that? Matt may be willing to work on that. If other folks are interested in contributing in that effort, let us know. Cheers Francois On 7 Nov 2013, at 20:50, "Brandenburg, R. (Ray) van" wrote: > Hi all, >=20 > I think Kevin raises an interesting point. It's not so much a capability = that you want to check for, it's something you want to mandate from a dCDN,= similar to how a uCDN might mandate other elements of the delivery process= . In that sense, the metadata interface is indeed a more appropriate interf= ace.=20 >=20 > (Now that we're discussing this, do we have to worry about people arguing= that mandating something that has to do with acquisition goes against the = charter which specifies the acquisition interface to be out of scope? :)) >=20 > Best regards, >=20 > Ray >=20 >> On 6 nov. 2013, at 16:43, "Kevin J Ma" wrote= : >>=20 >> Hi Scott, >>=20 >> My point was that: >>=20 >> wrt to 2), the dCDN can advertise its acquisition protocol capabilities. >> If it says it supports HTTP, it is assumed that it supports all of HTTP >> including range requests, so I see no reason to add an additional >> "Partial Caching" capability flag which essentially says: "yes I really >> do support range requests". If theres a dCDN that doesnt support range >> requests, then it should advertise some type of HTTP-lite for its >> acquisition protocol. That was a well debated use case for acquisition >> protocols, as I recall? >>=20 >> wrt to 1) and 3), the uCDN telling the dCDN how to acquire content is >> a completely separate issue. It is really a metadata issue, not a >> capability issue (given that the capability part should already be >> addressed through the acqusition protocol capability). >>=20 >> If what we are really looking for is a new HTTP-minus-range-gets >> protocol for the registry, and maybe a you-must-propogate-range-gets >> metadata, then that is a different discussion, and I would like to >> clarify that first? >>=20 >> thanx. >>=20 >> -- Kevin J. Ma >>=20 >>> -----Original Message----- >>> From: Scott Leibrand [mailto:sleibrand@llnw.com] >>> Sent: Wednesday, November 06, 2013 2:00 AM >>> To: Kevin J Ma >>> Cc: Jan Seedorf; Francois Le Faucheur (flefauch); Brandenburg, R. (Ray) >>> van; Larry Peterson; cdni@ietf.org; Daryl Malas >>> Subject: Re: Discussing a "Partial Caching" Capability (for byte-range >>> requests) in FCI semantics >>>=20 >>>=20 >>>>> On Nov 5, 2013, at 8:54 PM, Kevin J Ma >>>> wrote: >>>>=20 >>>> I have a couple clarifying questions about the partial caching: >>>>=20 >>>> 1. Is there text somewhere that states that dCDNs MUST only cache what >>>> the client requested? >>>>=20 >>>> Just because the dCDN is capable of partial caching, doesnt mean that >>>> it won't go ahead and ask for the whole file? >>>=20 >>> A uCDN (with a CSP customer with a very large video library) who is doi= ng >>> partial caching themselves needs their dCDNs to do something similar, a= nd >>> only request content that users actually request (modulo some read ahea= d >>> or whatever). Otherwise, the dCDN's requests blow up the active library= on >>> the uCDN's caches, causing them to have to double storage capacity to >>> cache portions of the content no one is watching. >>>=20 >>> If a dCDN doesn't support the capability to only ask for what they need= , >>> the uCDN may be better off serving the content themselves. >>>=20 >>>>=20 >>>> 2. If we assume the dCDN only does partial acquisition requests, when >>>> it receives a partial delivery request, then my question is, are >>>> we concerned that dCDN is incapable of doing range requests? If >>>> so, should that not show up in the acquisition protocol capability? >>>>=20 >>>> It's unclear to me what information the partial caching capability >>>> is actually conveying? >>>=20 >>> I'm not following. Range requests are how partial objects are transferr= ed. >>> If the dCDN doesn't support range requests, we have bigger problems. >>>=20 >>>>=20 >>>> 3. If what we really want is a way for the uCDN to tell the dCDN wheth= er >>>> or not to use partial caching for a given piece of content, then I >>>> would think what we need is a new metadata object, not a new >>> capability? >>>=20 >>> I'm not familiar enough with the spec to know what we need there. But t= he >>> central requirement is for the uCDN to be able to tell dCDNs to do part= ial >>> caching for a given CSP's content, and for the uCDN to be able to avoid >>> using any dCDNs that don't support partial caching. >>>=20 >>> -Scott >>>>=20 >>>> thanx. >>>>=20 >>>> -- Kevin J. Ma >>>>=20 >>>>> -----Original Message----- >>>>> From: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] >>>>> Sent: Tuesday, November 05, 2013 12:42 PM >>>>> To: Kevin J Ma; Francois Le Faucheur (flefauch) >>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg >>> (Ray); >>>>> Larry Peterson; cdni@ietf.org; Daryl Malas >>>>> Subject: RE: Discussing a "Partial Caching" Capability (for byte-rang= e >>>>> requests) in FCI semantics >>>>>=20 >>>>> Same here, we have not considered this, but sure let's discuss it >>> during >>>>> Thursday's lunch meeting >>>>>=20 >>>>> - Jan >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>>> Sent: Tuesday, November 05, 2013 5:16 PM >>>>>> To: Francois Le Faucheur (flefauch); Jan Seedorf >>>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg >>> (Ray); >>>>>> Larry Peterson; cdni@ietf.org; Daryl Malas >>>>>> Subject: RE: Discussing a "Partial Caching" Capability (for byte-ran= ge >>>>>> requests) in FCI semantics >>>>>>=20 >>>>>> i did not consider it, but i am happy to discuss it. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >>>>>> Sent: Tuesday, November 05, 2013 11:12 AM >>>>>> To: Jan Seedorf; Kevin J Ma >>>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg >>> (Ray); >>>>>> Francois Le Faucheur (flefauch); Larry Peterson; cdni@ietf.org; Dary= l >>>>> Malas >>>>>> Subject: Discussing a "Partial Caching" Capability (for byte-range >>>>> requests) in >>>>>> FCI semantics >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Jan, Kevin, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Did you consider the following? >>>>>>=20 >>>>>> Can we discuss it in Vancouver? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Tx >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) >>>>>> wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Scott, Jan, and all, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 15 Oct 2013, at 11:30, Scott Leibrand wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> This feature (partial object caching) is absolutely a requirement >>> before >>>>> we >>>>>> could think about offloading on-demand video traffic to a dCDN. If >>> the >>>>> dCDN >>>>>> downloads the entire file, that completely ruins the uCDN's efforts = to >>>>> do >>>>>> partial caching, and the resulting increase in cache use makes thing= s >>>>> worse >>>>>> than not using a dCDN at all. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Then perhaps it would make sense to include something like "Partial >>>>> Object >>>>>> Caching" in the set of capabilities that can be advertised in the CD= NI >>>>> Footprint >>>>>> and Capabilities Advertisement interface (FCI). This would allow the >>>>> uCDN to >>>>>> select a dCDN that supports partial object caching when required (or >>>>> possibly >>>>>> elect to serve itself). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Jan, >>>>>>=20 >>>>>> Would you mind including this as a candidate in your list so we >>> rememebr >>>>> to >>>>>> make a concious decision about it? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Thanks >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Francois >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -Scott >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van >>>>>> wrote: >>>>>>=20 >>>>>> Hi Ben, >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >>>>>>> Sent: maandag 14 oktober 2013 5:10 >>>>>>> To: Brandenburg, R. (Ray) van >>>>>>> Cc: cdni@ietf.org >>>>>>> Subject: Re: [CDNi] CDNI and byte-range requests >>>>>>>=20 >>>>>>> Ray, >>>>>>>=20 >>>>>>>> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> As I'm not sure whether this should be part of the Redirection >>>>> Interface >>>>>>> document or the Framework document, let me just post this as a >>> general >>>>>>> question to the list: >>>>>>>>=20 >>>>>>>> To my knowledge, the current CDNI documents do not explicitly >>>>> address >>>>>>> the case of HTTP Byte-range requests. Although in most cases byte- >>>>> range >>>>>>> requests will function just as any other requests, I think there ar= e >>>>> some >>>>>> cases >>>>>>> where byte-range requests warrant further attention. An example is >>> the >>>>>>> Redirection interface. If a uCDN asks a dCDN to deliver a particula= r >>>>> user >>>>>>> request (containing a byte range), and the dCDN answers positively, >>>>> can >>>>>> the >>>>>>> uCDN assume that the dCDN accepts any future requests for the same >>>>> file >>>>>>> with a different byte range? And if that is the case, is this defau= lt >>>>> behavior >>>>>> or >>>>>>> do we need an explicit flag in the inter-CDN redirection request to >>>>> indicate >>>>>>> the uCDN/dCDN's preference? >>>>>>>>=20 >>>>>>>> To be clear: I don't think we need any new functionality to handle >>>>> byte- >>>>>>> range requests, but a few sentences in either the Framework or the = RI >>>>>>> document might clear up any future uncertainty. >>>>>>>=20 >>>>>>> I don't see how this is any different to a sequence of non byte-ran= ge >>>>>>> requests. >>>>>>>=20 >>>>>>> It will likely depend on the behaviour of the client (and possibly >>>>> whether >>>>>> the >>>>>>> server closes the connection after each request if that drives a >>>>> different >>>>>>> client behaviour) as to where the client ends up going (uCDN or dCD= N) >>>>>> when >>>>>>> it makes a subsequent request. >>>>>>>=20 >>>>>>> Trying to say anything here may take us down the rat hole of trying >>> to >>>>>>> describe client behaviour which we don't control. >>>>>>=20 >>>>>> Let me give a practical example: Let's say the uCDN is hosting a 2gb >>> TS >>>>> file. At >>>>>> some point it receives an incoming request for a particular byte ran= ge >>>>> within >>>>>> that file, let's say the first 10mb. For some reason the uCDN decide= s >>>>> that it >>>>>> wants to redirect the request to a dCDN. The dCDN receives the >>> request. >>>>> At >>>>>> that point it has to decide what to do: does it download the full 2g= b >>>>> file from >>>>>> the uCDN, or does it download just the first 10mb? Of course it's >>> fully >>>>> up to >>>>>> internal logic in the dCDN to decide what it should do here, however >>> it >>>>> does >>>>>> have an impact on the uCDN as well (potentially unnecessary traffic >>>>> reducing >>>>>> the effectiveness of the inter-CDN redirect). My question is, do we >>> need >>>>> to >>>>>> say anything about this case to help both the dCDN and uCDN in makin= g >>>>> this >>>>>> decision? >>>>>>=20 >>>>>> Ray >>>>>>=20 >>>>>>=20 >>>>>>> Ben >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Ray >>>>>>>> This e-mail and its contents are subject to the DISCLAIMER at >>>>>>> http://www.tno.nl/emaildisclaimer >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> CDNi mailing list >>>>>>>> CDNi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>=20 >=20 >=20 >=20 > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u = niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden= , wordt u verzocht dat aan de afzender te melden en het bericht te verwijde= ren. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, d= e wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verb= and houdt met risico's verbonden aan het elektronisch verzenden van bericht= en. >=20 >=20 >=20 > This message may contain information that is not intended for you. If you= are not the addressee or if this message was sent to you by mistake, you a= re requested to inform the sender and delete the message. TNO accepts no li= ability for the content of this e-mail, for the manner in which you use it = and for damage of any kind resulting from the risks inherent to the electro= nic transmission of messages. >=20 From sleibrand@llnw.com Fri Nov 8 18:54:35 2013 Return-Path: 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 D162A21E80CC for ; Fri, 8 Nov 2013 18:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=-2.386, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58aXVCPB-UlY for ; Fri, 8 Nov 2013 18:54:31 -0800 (PST) Received: from exprod5og119.obsmtp.com (exprod5og119.obsmtp.com [64.18.0.189]) by ietfa.amsl.com (Postfix) with ESMTP id 7E69F21E80BA for ; Fri, 8 Nov 2013 18:54:31 -0800 (PST) Received: from mail-pd0-f170.google.com ([209.85.192.170]) (using TLSv1) by exprod5ob119.postini.com ([64.18.4.12]) with SMTP ID DSNKUn2j5uLaNtT9Ah2NBKbn2LN/5g3kOqcy@postini.com; Fri, 08 Nov 2013 18:54:31 PST Received: by mail-pd0-f170.google.com with SMTP id v10so2949999pde.29 for ; Fri, 08 Nov 2013 18:54:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:from:subject :date:to; bh=6e0kzdKzqEad708hEANDWEzI3QnU2lHV7vIewVYNSFA=; b=FSdOM+zVE20sxg1+KUilsnaFF9tyxG9yOg517Sl91RHorZCo0zb5LdYE/MjqdzRnj3 YTkgJo+SdokQwltvMafqg0ahhIzRoh74dkiiVEQJGKOBJRhnqoSPzElA9/DjXKxGnlTm uDxGMxkCRX8caV6Lzy/PPhFSksMZI25JlHHjmE3Y4mFd8Xflrj0pRjHti82ZrHz0KA/n IJX01mUtAhL4pVWZp0chF/B0FeZBdOUOJRfZffB8khZ4yAWsKZfw/CLZl1I+VSAob2is 3LygsrUVIPNIV0+mv9FW20GgPz5BtE2nRpk74Nvj31UjxY4X03T3fxv5h1XUshCizlRe ZSWw== X-Gm-Message-State: ALoCoQkkdUrebzz3doPO0gsiQ5w4x3ySGkSgU597B116s+BoOUDWr1zhTqmKOvC4FOsB1vQuk4Xh+RGDVpHf7iJbWcxWJ0C+roiKYa7456Nn9RucmiQxhP7YG0Cv/NJKDo6e1bYDGRe1QR5rjZWWy0Se/TswkWF44Q== X-Received: by 10.68.125.226 with SMTP id mt2mr18308450pbb.115.1383965669763; Fri, 08 Nov 2013 18:54:29 -0800 (PST) X-Received: by 10.68.125.226 with SMTP id mt2mr18308438pbb.115.1383965669629; Fri, 08 Nov 2013 18:54:29 -0800 (PST) Received: from ?IPv6:2601:8:8680:48e:99f9:664c:9526:14ec? ([2601:8:8680:48e:99f9:664c:9526:14ec]) by mx.google.com with ESMTPSA id hu10sm15284819pbc.11.2013.11.08.18.54.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 18:54:29 -0800 (PST) References: <89B634B5-60FA-4AE7-A924-B76D86096CC6@cisco.com> <291CC3F9E50E7641901A54E85D0977C6B027F5A1A2@MAILR002.mail.lan> <2779C9F0771F974CAD742BAE6D9904FE639DAC05@PALLENE.office.hd> <291CC3F9E50E7641901A54E85D0977C6B027F5A550@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6B027F5A648@MAILR002.mail.lan> <3204FE67-6E32-42ED-AC02-CA45B544F9C5@tno.nl> <6C0BCBC2-19CA-4C80-9657-DCE062835BA2@cisco.com> In-Reply-To: <6C0BCBC2-19CA-4C80-9657-DCE062835BA2@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (11B511) From: Scott Leibrand Date: Fri, 8 Nov 2013 18:54:27 -0800 To: "Francois Le Faucheur (flefauch)" Cc: "cdni@ietf.org" Subject: Re: [CDNi] Suggestion for progressing on "Partial Caching"/"Byte Range request" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 02:54:35 -0000 I'd be happy to help review/edit/whatever.=20 Scott > On Nov 8, 2013, at 5:32 PM, "Francois Le Faucheur (flefauch)" wrote: >=20 > Hi Ray and all, >=20 > Based on a few conversations here in Vancouver on that topic, I think hand= ling of Partial Caching in CDNI would involve: > * defining a Capability, so the dCDN can indicate in FCI whether/how it= supports "Partial Caching" (e.g. dCDN does not support Partial Caching, dCD= N support Partial Caching for all content, dCDN supports Partial Caching on a= per content item/set basis) > * defining an additional CDNI Metadata information Element, allowing th= e uCDN to tell the dCDN (or a per content item/content sets basis) whether "= partial Caching" is needed (or not) from dCDN when client issues a byte rang= e request to this content. Something like: > o Partial-Caching: dCDN needs to minimise the amount of data reque= sted on acquisition - eg by only acquiring the same byte range as requested b= y end-user,=20 > o No-Partial-Caching: dCDN is not required to minimise the amount o= f data requested on acquisition - ie dCDN behaves whichever way it wants. >=20 > A possible way to progress this would be to take a similar approach to wha= t is being done for rate-pacing, ie progress a standalone I-D that focuses o= n this functionality and defines the corresponding use case + overall functi= onality, and defines the impact and necessary extensions for each of the CDN= I interfaces. > Makes sense? >=20 > Would you be interested in driving that? > Matt may be willing to work on that. >=20 > If other folks are interested in contributing in that effort, let us know.= >=20 > Cheers >=20 > Francois >=20 >> On 7 Nov 2013, at 20:50, "Brandenburg, R. (Ray) van" wrote: >>=20 >> Hi all, >>=20 >> I think Kevin raises an interesting point. It's not so much a capability t= hat you want to check for, it's something you want to mandate from a dCDN, s= imilar to how a uCDN might mandate other elements of the delivery process. I= n that sense, the metadata interface is indeed a more appropriate interface.= =20 >>=20 >> (Now that we're discussing this, do we have to worry about people arguing= that mandating something that has to do with acquisition goes against the c= harter which specifies the acquisition interface to be out of scope? :)) >>=20 >> Best regards, >>=20 >> Ray >>=20 >>> On 6 nov. 2013, at 16:43, "Kevin J Ma" wrote= : >>>=20 >>> Hi Scott, >>>=20 >>> My point was that: >>>=20 >>> wrt to 2), the dCDN can advertise its acquisition protocol capabilities.= >>> If it says it supports HTTP, it is assumed that it supports all of HTTP >>> including range requests, so I see no reason to add an additional >>> "Partial Caching" capability flag which essentially says: "yes I really >>> do support range requests". If theres a dCDN that doesnt support range >>> requests, then it should advertise some type of HTTP-lite for its >>> acquisition protocol. That was a well debated use case for acquisition >>> protocols, as I recall? >>>=20 >>> wrt to 1) and 3), the uCDN telling the dCDN how to acquire content is >>> a completely separate issue. It is really a metadata issue, not a >>> capability issue (given that the capability part should already be >>> addressed through the acqusition protocol capability). >>>=20 >>> If what we are really looking for is a new HTTP-minus-range-gets >>> protocol for the registry, and maybe a you-must-propogate-range-gets >>> metadata, then that is a different discussion, and I would like to >>> clarify that first? >>>=20 >>> thanx. >>>=20 >>> -- Kevin J. Ma >>>=20 >>>> -----Original Message----- >>>> From: Scott Leibrand [mailto:sleibrand@llnw.com] >>>> Sent: Wednesday, November 06, 2013 2:00 AM >>>> To: Kevin J Ma >>>> Cc: Jan Seedorf; Francois Le Faucheur (flefauch); Brandenburg, R. (Ray)= >>>> van; Larry Peterson; cdni@ietf.org; Daryl Malas >>>> Subject: Re: Discussing a "Partial Caching" Capability (for byte-range >>>> requests) in FCI semantics >>>>=20 >>>>=20 >>>>>> On Nov 5, 2013, at 8:54 PM, Kevin J Ma >>>>> wrote: >>>>>=20 >>>>> I have a couple clarifying questions about the partial caching: >>>>>=20 >>>>> 1. Is there text somewhere that states that dCDNs MUST only cache what= >>>>> the client requested? >>>>>=20 >>>>> Just because the dCDN is capable of partial caching, doesnt mean that >>>>> it won't go ahead and ask for the whole file? >>>>=20 >>>> A uCDN (with a CSP customer with a very large video library) who is doi= ng >>>> partial caching themselves needs their dCDNs to do something similar, a= nd >>>> only request content that users actually request (modulo some read ahea= d >>>> or whatever). Otherwise, the dCDN's requests blow up the active library= on >>>> the uCDN's caches, causing them to have to double storage capacity to >>>> cache portions of the content no one is watching. >>>>=20 >>>> If a dCDN doesn't support the capability to only ask for what they need= , >>>> the uCDN may be better off serving the content themselves. >>>>=20 >>>>>=20 >>>>> 2. If we assume the dCDN only does partial acquisition requests, when >>>>> it receives a partial delivery request, then my question is, are >>>>> we concerned that dCDN is incapable of doing range requests? If >>>>> so, should that not show up in the acquisition protocol capability? >>>>>=20 >>>>> It's unclear to me what information the partial caching capability >>>>> is actually conveying? >>>>=20 >>>> I'm not following. Range requests are how partial objects are transferr= ed. >>>> If the dCDN doesn't support range requests, we have bigger problems. >>>>=20 >>>>>=20 >>>>> 3. If what we really want is a way for the uCDN to tell the dCDN wheth= er >>>>> or not to use partial caching for a given piece of content, then I >>>>> would think what we need is a new metadata object, not a new >>>> capability? >>>>=20 >>>> I'm not familiar enough with the spec to know what we need there. But t= he >>>> central requirement is for the uCDN to be able to tell dCDNs to do part= ial >>>> caching for a given CSP's content, and for the uCDN to be able to avoid= >>>> using any dCDNs that don't support partial caching. >>>>=20 >>>> -Scott >>>>>=20 >>>>> thanx. >>>>>=20 >>>>> -- Kevin J. Ma >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] >>>>>> Sent: Tuesday, November 05, 2013 12:42 PM >>>>>> To: Kevin J Ma; Francois Le Faucheur (flefauch) >>>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg >>>> (Ray); >>>>>> Larry Peterson; cdni@ietf.org; Daryl Malas >>>>>> Subject: RE: Discussing a "Partial Caching" Capability (for byte-rang= e >>>>>> requests) in FCI semantics >>>>>>=20 >>>>>> Same here, we have not considered this, but sure let's discuss it >>>> during >>>>>> Thursday's lunch meeting >>>>>>=20 >>>>>> - Jan >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>>>> Sent: Tuesday, November 05, 2013 5:16 PM >>>>>>> To: Francois Le Faucheur (flefauch); Jan Seedorf >>>>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg >>>> (Ray); >>>>>>> Larry Peterson; cdni@ietf.org; Daryl Malas >>>>>>> Subject: RE: Discussing a "Partial Caching" Capability (for byte-ran= ge >>>>>>> requests) in FCI semantics >>>>>>>=20 >>>>>>> i did not consider it, but i am happy to discuss it. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >>>>>>> Sent: Tuesday, November 05, 2013 11:12 AM >>>>>>> To: Jan Seedorf; Kevin J Ma >>>>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg >>>> (Ray); >>>>>>> Francois Le Faucheur (flefauch); Larry Peterson; cdni@ietf.org; Dary= l >>>>>> Malas >>>>>>> Subject: Discussing a "Partial Caching" Capability (for byte-range >>>>>> requests) in >>>>>>> FCI semantics >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Jan, Kevin, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Did you consider the following? >>>>>>>=20 >>>>>>> Can we discuss it in Vancouver? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Tx >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) >>>>>>> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Scott, Jan, and all, >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 15 Oct 2013, at 11:30, Scott Leibrand wrote:= >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> This feature (partial object caching) is absolutely a requirement >>>> before >>>>>> we >>>>>>> could think about offloading on-demand video traffic to a dCDN. If >>>> the >>>>>> dCDN >>>>>>> downloads the entire file, that completely ruins the uCDN's efforts t= o >>>>>> do >>>>>>> partial caching, and the resulting increase in cache use makes thing= s >>>>>> worse >>>>>>> than not using a dCDN at all. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Then perhaps it would make sense to include something like "Partial >>>>>> Object >>>>>>> Caching" in the set of capabilities that can be advertised in the CD= NI >>>>>> Footprint >>>>>>> and Capabilities Advertisement interface (FCI). This would allow the= >>>>>> uCDN to >>>>>>> select a dCDN that supports partial object caching when required (or= >>>>>> possibly >>>>>>> elect to serve itself). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Jan, >>>>>>>=20 >>>>>>> Would you mind including this as a candidate in your list so we >>>> rememebr >>>>>> to >>>>>>> make a concious decision about it? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Thanks >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Francois >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -Scott >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van >>>>>>> wrote: >>>>>>>=20 >>>>>>> Hi Ben, >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >>>>>>>> Sent: maandag 14 oktober 2013 5:10 >>>>>>>> To: Brandenburg, R. (Ray) van >>>>>>>> Cc: cdni@ietf.org >>>>>>>> Subject: Re: [CDNi] CDNI and byte-range requests >>>>>>>>=20 >>>>>>>> Ray, >>>>>>>>=20 >>>>>>>>> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: >>>>>>>>>=20 >>>>>>>>> Hi all, >>>>>>>>>=20 >>>>>>>>> As I'm not sure whether this should be part of the Redirection >>>>>> Interface >>>>>>>> document or the Framework document, let me just post this as a >>>> general >>>>>>>> question to the list: >>>>>>>>>=20 >>>>>>>>> To my knowledge, the current CDNI documents do not explicitly >>>>>> address >>>>>>>> the case of HTTP Byte-range requests. Although in most cases byte- >>>>>> range >>>>>>>> requests will function just as any other requests, I think there ar= e >>>>>> some >>>>>>> cases >>>>>>>> where byte-range requests warrant further attention. An example is >>>> the >>>>>>>> Redirection interface. If a uCDN asks a dCDN to deliver a particula= r >>>>>> user >>>>>>>> request (containing a byte range), and the dCDN answers positively,= >>>>>> can >>>>>>> the >>>>>>>> uCDN assume that the dCDN accepts any future requests for the same >>>>>> file >>>>>>>> with a different byte range? And if that is the case, is this defau= lt >>>>>> behavior >>>>>>> or >>>>>>>> do we need an explicit flag in the inter-CDN redirection request to= >>>>>> indicate >>>>>>>> the uCDN/dCDN's preference? >>>>>>>>>=20 >>>>>>>>> To be clear: I don't think we need any new functionality to handle= >>>>>> byte- >>>>>>>> range requests, but a few sentences in either the Framework or the R= I >>>>>>>> document might clear up any future uncertainty. >>>>>>>>=20 >>>>>>>> I don't see how this is any different to a sequence of non byte-ran= ge >>>>>>>> requests. >>>>>>>>=20 >>>>>>>> It will likely depend on the behaviour of the client (and possibly >>>>>> whether >>>>>>> the >>>>>>>> server closes the connection after each request if that drives a >>>>>> different >>>>>>>> client behaviour) as to where the client ends up going (uCDN or dCD= N) >>>>>>> when >>>>>>>> it makes a subsequent request. >>>>>>>>=20 >>>>>>>> Trying to say anything here may take us down the rat hole of trying= >>>> to >>>>>>>> describe client behaviour which we don't control. >>>>>>>=20 >>>>>>> Let me give a practical example: Let's say the uCDN is hosting a 2gb= >>>> TS >>>>>> file. At >>>>>>> some point it receives an incoming request for a particular byte ran= ge >>>>>> within >>>>>>> that file, let's say the first 10mb. For some reason the uCDN decide= s >>>>>> that it >>>>>>> wants to redirect the request to a dCDN. The dCDN receives the >>>> request. >>>>>> At >>>>>>> that point it has to decide what to do: does it download the full 2g= b >>>>>> file from >>>>>>> the uCDN, or does it download just the first 10mb? Of course it's >>>> fully >>>>>> up to >>>>>>> internal logic in the dCDN to decide what it should do here, however= >>>> it >>>>>> does >>>>>>> have an impact on the uCDN as well (potentially unnecessary traffic >>>>>> reducing >>>>>>> the effectiveness of the inter-CDN redirect). My question is, do we >>>> need >>>>>> to >>>>>>> say anything about this case to help both the dCDN and uCDN in makin= g >>>>>> this >>>>>>> decision? >>>>>>>=20 >>>>>>> Ray >>>>>>>=20 >>>>>>>=20 >>>>>>>> Ben >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Best regards, >>>>>>>>>=20 >>>>>>>>> Ray >>>>>>>>> This e-mail and its contents are subject to the DISCLAIMER at >>>>>>>> http://www.tno.nl/emaildisclaimer >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> CDNi mailing list >>>>>>>>> CDNi@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> CDNi mailing list >>>>>>> CDNi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> CDNi mailing list >>>>>>> CDNi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>=20 >>=20 >>=20 >>=20 >> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u n= iet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, w= ordt u verzocht dat aan de afzender te melden en het bericht te verwijderen.= TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wij= ze waarop u deze gebruikt en voor schade, van welke aard ook, die verband ho= udt met risico's verbonden aan het elektronisch verzenden van berichten. >>=20 >>=20 >>=20 >> This message may contain information that is not intended for you. If you= are not the addressee or if this message was sent to you by mistake, you ar= e requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it and= for damage of any kind resulting from the risks inherent to the electronic t= ransmission of messages. >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Sat Nov 9 12:04:16 2013 Return-Path: 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 B5E0211E8189 for ; Sat, 9 Nov 2013 12:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrC2QnGDBRHS for ; Sat, 9 Nov 2013 12:04:11 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 37D1811E8175 for ; Sat, 9 Nov 2013 12:04:11 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 615878BEBDB for ; Sat, 9 Nov 2013 15:04:10 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 969C38BEBC7 for ; Sat, 9 Nov 2013 15:04:09 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Sat, 9 Nov 2013 15:04:09 -0500 From: Kevin J Ma To: "cdni@ietf.org" Date: Sat, 9 Nov 2013 15:04:04 -0500 Thread-Topic: review of draft-ietf-cdni-logging-08 Thread-Index: Ac7dhDqLe1eOlV+TSaKs71I0g+SB/Q== Message-ID: <291CC3F9E50E7641901A54E85D0977C6B028025C59@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] review of draft-ietf-cdni-logging-08 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 20:04:16 -0000 Hi All, As per the chair's edict, I have produced a detailed review of draft-ietf-cdni-logging-08, within the allotted seven days. Note: There are a lot of comments. I was pretty nit-picky in the hope of making Daryl's life easier. Sorry Iuniana. ;-) thanx. -- Kevin J. Ma comments: - general: There is inconsistency between the use of "End-User" and "End User", with one stray "end user" and a stray "enduser". These should be cleaned up for consistency. - general: There is an inconsistency with comma usage after "i.e." (vs. "i.e.,") and "e.g." (vs. "e.g.,"). These should be cleaned up for consistency. - general: What does "in future version of this document" mean? Does it mean a new RFC that obsoletes this RFC? Should these notes instead refer to a future version of the protocol? Or should they just state that things are out of scope? - section 1.1: wrt the following statement: "we use the word "Log" only for referring to internal CDN logs and we use the word "Logging" for any inter-CDN information exchange and processing operations related to CDNI Logging interface." should use of the lower case "log" and "logging" throughout the document be interpreted as generic terms, without distinction for local CDN vs CDNI? Certain cases seem as though they should be capitalized. I did not enumerate these in this review. - section 2.2.4: I found this clause to be very confusing: "In the case where the log-generating entities have generated during- generation aggregate logs" Perhaps it would be easier to just say: "In the case where aggregate logs have been generated" - section 3.2: The first sentance notes that Logging Fields and Records are defined in 1.1. Logging Files are also defined in 1.1, but the second sentance caused me to second guess this: "As defined in Section 1.1 a CDNI logging field is as an atomic logging information element and a CDNI Logging Record is a collection of CDNI Logging Fields containing all logging information corresponding to a single logging event. This document defines a third level of structure, the CDNI Logging File, that is a collection of CDNI Logging Records." Perhaps it would be more clear to just say: "As defined in Section 1.1: a CDNI logging field is as an atomic logging information element, a CDNI Logging Record is a collection of CDNI Logging Fields containing all logging information corresponding to a single logging event, and a CDNI Logging File contains is a collection of CDNI Logging Records." - section 3.3: I think we should define a restriction on DIRNAME to be not COLON (":")? Perhaps even just alphanumberic plus dash and underscore? This should be enforced by the IANA reviewer? - section 3.3: The DIRVAL should be specified by the reference document in the CDNI Logging Directive Names registry (Section 5.1). The BNF should note that. The fact that the initial directives are defined in this document is a degenerate case of generic DIRVALs. " DIRVAL =3D " - section 3.3: For any directive with a format defined as NHTABSTRING, don't we also need to exclude CRLF from the string? - section 3.3: For the Record-Type directive, I think it would be more clear to change: "precede any CDNI Logging Record" -> "MUST precede all CDNI Logging Records" - section 3.3: I think we should define a restriction on FIENAME to be not HTAB and not CRLF? Perhaps even just alphanumberic plus dash and underscore? This should be enforced by the IANA reviewer? - section 3.3: It was not clear to me initially, what this sentance is attempting to say. 3.4 has an example of a logging record and its list of fields, but it's not the only possible logging record, it's just the first one defined. When I first read this, I interpreted it as all possible logging records are defined in 3.4. " The names of the fields, as well as their possible occurrences, are specified for each type of CDNI Logging Records in Section 3.4." Perhaps it couldbe clarified to say something like: " The names of the fields, as well as their possible occurrences, MUST be specified in the referenced document of the CDNI Logging Record-types registry (Section 5.2), for each CDNI Logging Record-Type. This document defines the names of the fields, as well as their possible occurrences, for the "cdni_http_request_v1" Record-Type in Section 3.4.1." - section 3.3: Just to clarify, this statement asserts that the file is "non-corrupted", but makes no guarantee that it is tamper-proof or tamper-evident (a la MITM attack)? " If the two values are equal, then the received CDNI Logging File MUST be considered non-corrupted." - section 3.4.1: For any field value with a format defined as NHTABSTRING, don't we also need to exclude CRLF from the string? - section 3.4.1: For protocol, do we want this to be extensible to HTTP/2.0? Does the normative reference to RFC2616 restrict this to HTTP/1.0 and HTTP/1.1? I had assumed that the v1 in "cdni_http_request_v1" referred to the Logging Record version, but perhaps it instead refers to the HTTP version? This is probably worth clarifying. - section 3.4.1: In the sc-total-bytes and sc-entity-bytes field value descriptions, the parenthetical references to HTTP headers seems to imply some inherent relationship between the headers and the status line, which I do not believe exists, per section 6 of RFC2616. " This includes the bytes of the Status-Line (including HTTP headers)" " This does not include the bytes of the Status-Line (and therefore does not include the bytes of the HTTP headers)". I think it would be clearer to say: " This includes the bytes of the Status-Line and the bytes of the HTTP headers" " This does not include the bytes of the Status-Line or the bytes of the HTTP headers". - section 3.4.1: For all the fields values whos format is QSTRING, the field value description should be updated to indicate that the value is not actually "as received" or "as it appears in the response", etc., but rather that value encased in double quotes with any double quotes in that value escaped by an additional double quote? - section 3.4.1: I found the following text odd, in that the normative statement is that the value must be either something or nothing, which is somewhat tautological. Should this just be a MAY since its optional? " there MUST be zero, one or any number of instance" - section 3.4.1: For the s-sid field, is the only allowable use of this field for HAS delivery? Or can the field be used to group requests for any content? If it is really the latter, this should be clarified. " this contains the value of a Session IDentifier generated by the dCDN for a specific HTTP Adaptive Streaming (HAS) session" - section 3.4.1: Is it really the logging implementation that selects the fields? That does not sound correct to me? I would suggest removing: "by the implementation generating the CDNI Logging File" from this text: "The set of such fields name actually listed in the "Fields" directive is selected by the implementation generating the CDNI Logging File based on agreements between the interconnected CDNs established through" - section 3.4.1: I would suggestion removing "in that case, " from this sentance: "When such a field name is listed in the "Fields" directive, the corresponding field value MUST be included in the Logging Record; in that case, if the value for the field is not available, this MUST be conveyed via a dash character ("-")." - section 3.4.1: Just to clarify, the following text is defining the MTI fields for dCDNs. "A dCDN-side implementation of the CDNI Logging interface MUST support the ability to include valid values for the following Logging Fields" Would it be valid to always put a dash ("-")? Dash is a valid value, but does not require the dCDN to actually support parsing/producing any given field. - section 3.5: The UUID directive is not QSTRING, its NHTABSTRING, so can I assume that the double quotes are actually part of the UUID? Or is this example incorrect? " #UUID:"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"" - section 4.1: The terms "server-side" and "client-side" essentially refer to the "dCDN" and "uCDN", respectively, correct? I think it would be easier to follow if we used "dCDN" and "uCDN" since client and server are used for other purposes with other meanings in other parts of the draft. - section 4.1.1: What is an "IRI"? Should that be "URI" or "URN"? - section 4.1.2: Just to clarify, the "archive document" refers to past contents of the atom feed, correct? This section makes no statement about how long old logging files should be kept for, only how long old atom feed documents are held for? Should we? - section 4.2: Do we have thoughts on future HTTP/2.0 support? Not that I necessarily think that things like multiplexing would necessarily be beneficial to log retrieval, but should we consider the possibility of HTTP/2.0 obsoleting HTTP/1.1 in a few years? Would we have to rev the LI RFC at that point? " MUST use HTTP v1.1 ( [RFC2616]);" - section 5.1: Should we add instructions to the implied expert reviewer requiring that each specification defining a new directive contain the same type of information for each directive as in 3.3 (i.e., format, directive value, and occurrence)? - section 5.2: Should we add instructions to the implied expert reviewer requiring that each specification defining a new record-type contain the same type of information for each field as in 3.4.1 (i.e., field name, format, field value, and occurrence)? - section 5.3: Should the Field Names registry really be a subregistry under the Record-types registry? Without the scope of the Record-Type, these field names cannot be used for any other Record-Type, e.g., "date" and "time" can only ever be used by cdni_http_request_v1? Or at a minimum, they must have the exact same meaning? If that is the intent, then we may want to make that explicit in the text. - section 6.1: I believe this is implying that mutual authentication SHOULD be used? Should that be made explicit? " the dCDN and uCDN to authenticate each other (to ensure they are transmitting/receiving CDNI Logging File from an authenticated CDN) - section 6.1: Do we want to make an explicit statement about privacy of End-User information? And possibly an explicit statement about the acceptability of alternate methods for ensuring confidentiality of End-User information (e.g., an IPSec tunnel between CDNs, or physically secured internal network between two CDNs owned by the same corporate entity)? " the CDNI Logging information to be transmitted with confidentiality" Note: The privacy section (6.3) talks about anonymization between dCDN and uCDN, however, this is more about leaking even anonymized data. - appendix A: Is this going to be removed? nits: - section 1.1: "real time" -> "real-time" - section 2.1: ", uCDN uses" -> ", the uCDN uses" - section 2.1: "delivery operated by" -> "delivery performed by" - section 2.1: "non real-time" -> "non-real-time" - section 2.1: "to CSP." -> "to the CSP." - section 2.1: ", uCDN merges" -> ", the uCDN merges" - section 2.1: ". uCDN may also" -> ". the uCDN may also" - section 2.1: "on his behalf." -> "on the CSP's behalf." - section 2.1: "e.g., dCDN-3" -> "i.e., dCDN-3" - section 2.1: "format that are" -> "formats that are" - section 2.2: "more or less" -> "more or fewer" - section 2.2: "i.e., there may be" -> "e.g., there may be" - section 2.2.3: "may require to" -> "may be required to" - section 2.2.3: "by every Surrogate" -> "by each Surrogate" - section 2.2.3: "hostnames is not" -> "hostnames are not" - section 2.2.4: "real time" -> "real-time" - section 2.2.5.6.2: "uCDN and dCDN may" -> "the uCDN and dCDN may" - section 2.2.5.6.2: "Top 10 of the most" -> "Top 10 most" - section 3.2: "CDNI logging field" -> "CDNI Logging Field" - section 3.2: "close to intra-CDN logging format" -> "close to the intra-CDN Log format" - section 3.3: "File ." -> "File." - section 3.3: "to HTTP request" -> "to HTTP requests" - section 3.3: "each type of CDNI Logging Records" -> "each type of CDNI Logging Record" - section 3.4.1: "prededing" -> "preceding" - section 3.4.1: "any number of instance" -> "any number of instances" - section 3.4.1: "dCDN i.e." -> "dCDN, i.e., " - section 3.4.1: "MUST list all the fields name whose" -> "MUST contain all the field names whose" - section 3.4.1: "The fields name" -> "The field names" - section 3.4.1: "cs- method" -> "cs-method" - section 3.4.1: "sc- total-bytes" -> "sc-total-bytes" - section 4: "each of these CDNI Logging File" -> "each of these CDNI Logging Files" - section 4: "at the uCDN convenience" -> "at the uCDN's convenience" - section 4: "as per the present document generating CDNI Logging file" -> ", as per the present document, generating CDNI Logging files" - section 4: "as per the present document consuming CDNI Logging file" -> ", as per the present document, consuming CDNI Logging files" - section 4: "document ." -> "document." - section 4.1.2: "MAY be unable to serve" -> "MAY indicate its inability to serve" - section 4.1.3: "redundancy, CDNI Logging" -> "redundancy. CDNI Logging" - section 4.2: "( [RFC2616])" -> "[RFC2616]" - section 4.2: "MAY be unable to serve" -> "MAY indicate its inability to serve" - section 6.3: "such as how much bytes of the content has been watched" -> "such as how many bytes of the content have been watched" From D.Malas@cablelabs.com Mon Nov 11 17:41:54 2013 Return-Path: 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 4754521E8136 for ; Mon, 11 Nov 2013 17:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.48 X-Spam-Level: X-Spam-Status: No, score=-100.48 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrYB7t9v+XEp for ; Mon, 11 Nov 2013 17:41:50 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 500AA21F9B5A for ; Mon, 11 Nov 2013 17:41:50 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id rAC1fZiQ004711; Mon, 11 Nov 2013 18:41:36 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 11 Nov 2013 18:41:35 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Mon, 11 Nov 2013 18:41:35 -0700 From: Daryl Malas To: Kevin J Ma , "cdni@ietf.org" Thread-Topic: [CDNi] review of draft-ietf-cdni-logging-08 Thread-Index: Ac7dhDqLe1eOlV+TSaKs71I0g+SB/QCSjGKA Date: Tue, 12 Nov 2013 01:41:34 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B028025C59@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="Windows-1252" Content-ID: <16C4FD49666BBE4F9C35F714575F88B9@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [CDNi] review of draft-ietf-cdni-logging-08 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 01:41:54 -0000 Thanks, Kevin. I greatly appreciate it, both timing and detail!! =8BDaryl On 11/9/13, 1:04 PM, "Kevin J Ma" wrote: >Hi All, > > As per the chair's edict, I have produced a detailed review of > draft-ietf-cdni-logging-08, within the allotted seven days. > > Note: There are a lot of comments. I was pretty nit-picky in > the hope of making Daryl's life easier. Sorry Iuniana. ;-) > >thanx. > >-- Kevin J. Ma > >comments: > >- general: There is inconsistency between the use of "End-User" and > "End User", with one stray "end user" and a stray "enduser". > These should be cleaned up for consistency. > >- general: There is an inconsistency with comma usage after "i.e." (vs. > "i.e.,") and "e.g." (vs. "e.g.,"). These should be cleaned > up for consistency. > >- general: What does "in future version of this document" mean? Does > it mean a new RFC that obsoletes this RFC? Should these > notes instead refer to a future version of the protocol? > Or should they just state that things are out of scope? > >- section 1.1: wrt the following statement: > > "we use the word "Log" only for referring to internal CDN > logs and we use the word "Logging" for any inter-CDN information > exchange and processing operations related to CDNI Logging >interface." > > should use of the lower case "log" and "logging" > throughout the document be interpreted as generic > terms, without distinction for local CDN vs CDNI? > Certain cases seem as though they should be capitalized. > I did not enumerate these in this review. > >- section 2.2.4: I found this clause to be very confusing: > > "In the case where the log-generating entities have generated during- > generation aggregate logs" > > Perhaps it would be easier to just say: > > "In the case where aggregate logs have been generated" > >- section 3.2: The first sentance notes that Logging Fields and > Records are defined in 1.1. Logging Files are also > defined in 1.1, but the second sentance caused me to > second guess this: > > "As defined in Section 1.1 a CDNI logging field is as an atomic > logging information element and a CDNI Logging Record is a collection > of CDNI Logging Fields containing all logging information > corresponding to a single logging event. This document defines a > third level of structure, the CDNI Logging File, that is a collection > of CDNI Logging Records." > > Perhaps it would be more clear to just say: > > "As defined in Section 1.1: a CDNI logging field is as an atomic > logging information element, a CDNI Logging Record is a collection > of CDNI Logging Fields containing all logging information > corresponding to a single logging event, and a CDNI Logging File > contains is a collection of CDNI Logging Records." > >- section 3.3: I think we should define a restriction on DIRNAME to be > not COLON (":")? Perhaps even just alphanumberic plus > dash and underscore? This should be enforced by the > IANA reviewer? > >- section 3.3: The DIRVAL should be specified by the reference > document in the CDNI Logging Directive Names registry > (Section 5.1). The BNF should note that. The fact > that the initial directives are defined in this > document is a degenerate case of generic DIRVALs. > > " DIRVAL =3D name>" > >- section 3.3: For any directive with a format defined as NHTABSTRING, > don't we also need to exclude CRLF from the string? > >- section 3.3: For the Record-Type directive, I think it would be more > clear to change: "precede any CDNI Logging Record" -> > "MUST precede all CDNI Logging Records" > >- section 3.3: I think we should define a restriction on FIENAME to be > not HTAB and not CRLF? Perhaps even just alphanumberic > plus dash and underscore? This should be enforced by > the IANA reviewer? > >- section 3.3: It was not clear to me initially, what this sentance is > attempting to say. 3.4 has an example of a logging > record and its list of fields, but it's not the only > possible logging record, it's just the first one > defined. When I first read this, I interpreted it as > all possible logging records are defined in 3.4. > > " The names of the fields, as well as their > possible occurrences, are specified for each type of CDNI > Logging Records in Section 3.4." > > Perhaps it couldbe clarified to say something like: > > " The names of the fields, as well as their > possible occurrences, MUST be specified in the referenced > document of the CDNI Logging Record-types registry (Section > 5.2), for each CDNI Logging Record-Type. This document > defines the names of the fields, as well as their possible > occurrences, for the "cdni_http_request_v1" Record-Type in > Section 3.4.1." > >- section 3.3: Just to clarify, this statement asserts that the file > is "non-corrupted", but makes no guarantee that it is > tamper-proof or tamper-evident (a la MITM attack)? > > " If the > two values are equal, then the received CDNI Logging File MUST > be considered non-corrupted." > >- section 3.4.1: For any field value with a format defined as > NHTABSTRING, don't we also need to exclude CRLF from > the string? > >- section 3.4.1: For protocol, do we want this to be extensible to > HTTP/2.0? Does the normative reference to RFC2616 > restrict this to HTTP/1.0 and HTTP/1.1? > > I had assumed that the v1 in "cdni_http_request_v1" > referred to the Logging Record version, but perhaps > it instead refers to the HTTP version? This is > probably worth clarifying. > >- section 3.4.1: In the sc-total-bytes and sc-entity-bytes field value > descriptions, the parenthetical references to HTTP > headers seems to imply some inherent relationship > between the headers and the status line, which I do > not believe exists, per section 6 of RFC2616. > > " This includes the bytes of the Status-Line (including HTTP > headers)" > > " This does not include the bytes of the Status-Line > (and therefore does not include the bytes of the HTTP headers)". > > I think it would be clearer to say: > > " This includes the bytes of the Status-Line and the bytes > of the HTTP headers" > > " This does not include the bytes of the Status-Line > or the bytes of the HTTP headers". > >- section 3.4.1: For all the fields values whos format is QSTRING, the > field value description should be updated to indicate > that the value is not actually "as received" or "as > it appears in the response", etc., but rather that > value encased in double quotes with any double quotes > in that value escaped by an additional double quote? > >- section 3.4.1: I found the following text odd, in that the normative > statement is that the value must be either something or > nothing, which is somewhat tautological. Should this > just be a MAY since its optional? > > " there MUST be zero, one or any number of instance" > >- section 3.4.1: For the s-sid field, is the only allowable use of > this field for HAS delivery? Or can the field be > used to group requests for any content? If it is > really the latter, this should be clarified. > > " this contains the value of a Session IDentifier > generated by the dCDN for a specific HTTP Adaptive Streaming > (HAS) session" > >- section 3.4.1: Is it really the logging implementation that selects > the fields? That does not sound correct to me? I > would suggest removing: "by the implementation > generating the CDNI Logging File" from this text: > > "The set > of such fields name actually listed in the "Fields" directive is > selected by the implementation generating the CDNI Logging File based > on agreements between the interconnected CDNs established through" > >- section 3.4.1: I would suggestion removing "in that case, " from > this sentance: > > "When such a field name is listed in the "Fields" > directive, the corresponding field value MUST be included in the > Logging Record; in that case, if the value for the field is not > available, this MUST be conveyed via a dash character ("-")." > >- section 3.4.1: Just to clarify, the following text is defining the > MTI fields for dCDNs. > > "A dCDN-side implementation of the CDNI Logging interface MUST support > the ability to include valid values for the following Logging Fields" > > Would it be valid to always put a dash ("-")? Dash > is a valid value, but does not require the dCDN to > actually support parsing/producing any given field. > >- section 3.5: The UUID directive is not QSTRING, its NHTABSTRING, so > can I assume that the double quotes are actually part > of the UUID? Or is this example incorrect? > > " #UUID:"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"" > >- section 4.1: The terms "server-side" and "client-side" essentially > refer to the "dCDN" and "uCDN", respectively, correct? > I think it would be easier to follow if we used "dCDN" > and "uCDN" since client and server are used for other > purposes with other meanings in other parts of the draft. > >- section 4.1.1: What is an "IRI"? Should that be "URI" or "URN"? > >- section 4.1.2: Just to clarify, the "archive document" refers to > past contents of the atom feed, correct? This > section makes no statement about how long old logging > files should be kept for, only how long old atom feed > documents are held for? Should we? > >- section 4.2: Do we have thoughts on future HTTP/2.0 support? Not > that I necessarily think that things like multiplexing > would necessarily be beneficial to log retrieval, but > should we consider the possibility of HTTP/2.0 > obsoleting HTTP/1.1 in a few years? Would we have to > rev the LI RFC at that point? > > " MUST use HTTP v1.1 ( [RFC2616]);" > >- section 5.1: Should we add instructions to the implied expert > reviewer requiring that each specification defining a > new directive contain the same type of information for > each directive as in 3.3 (i.e., format, directive > value, and occurrence)? > >- section 5.2: Should we add instructions to the implied expert > reviewer requiring that each specification defining a > new record-type contain the same type of information > for each field as in 3.4.1 (i.e., field name, format, > field value, and occurrence)? > >- section 5.3: Should the Field Names registry really be a subregistry > under the Record-types registry? Without the scope of > the Record-Type, these field names cannot be used for > any other Record-Type, e.g., "date" and "time" can only > ever be used by cdni_http_request_v1? Or at a minimum, > they must have the exact same meaning? If that is the > intent, then we may want to make that explicit in the > text. > >- section 6.1: I believe this is implying that mutual authentication > SHOULD be used? Should that be made explicit? > > " the dCDN and uCDN to authenticate each other (to ensure they are > transmitting/receiving CDNI Logging File from an authenticated > CDN) > >- section 6.1: Do we want to make an explicit statement about privacy > of End-User information? And possibly an explicit > statement about the acceptability of alternate methods > for ensuring confidentiality of End-User information > (e.g., an IPSec tunnel between CDNs, or physically > secured internal network between two CDNs owned by the > same corporate entity)? > > " the CDNI Logging information to be transmitted with > confidentiality" > > Note: The privacy section (6.3) talks about > anonymization between dCDN and uCDN, however, > this is more about leaking even anonymized data. > >- appendix A: Is this going to be removed? > >nits: > >- section 1.1: "real time" -> "real-time" > >- section 2.1: ", uCDN uses" -> ", the uCDN uses" > >- section 2.1: "delivery operated by" -> "delivery performed by" > >- section 2.1: "non real-time" -> "non-real-time" > >- section 2.1: "to CSP." -> "to the CSP." > >- section 2.1: ", uCDN merges" -> ", the uCDN merges" > >- section 2.1: ". uCDN may also" -> ". the uCDN may also" > >- section 2.1: "on his behalf." -> "on the CSP's behalf." > >- section 2.1: "e.g., dCDN-3" -> "i.e., dCDN-3" > >- section 2.1: "format that are" -> "formats that are" > >- section 2.2: "more or less" -> "more or fewer" > >- section 2.2: "i.e., there may be" -> "e.g., there may be" > >- section 2.2.3: "may require to" -> "may be required to" > >- section 2.2.3: "by every Surrogate" -> "by each Surrogate" > >- section 2.2.3: "hostnames is not" -> "hostnames are not" > >- section 2.2.4: "real time" -> "real-time" > >- section 2.2.5.6.2: "uCDN and dCDN may" -> "the uCDN and dCDN may" > >- section 2.2.5.6.2: "Top 10 of the most" -> "Top 10 most" > >- section 3.2: "CDNI logging field" -> "CDNI Logging Field" > >- section 3.2: "close to intra-CDN logging format" -> > "close to the intra-CDN Log format" > >- section 3.3: "File ." -> "File." > >- section 3.3: "to HTTP request" -> "to HTTP requests" > >- section 3.3: "each type of CDNI Logging Records" -> > "each type of CDNI Logging Record" > >- section 3.4.1: "prededing" -> "preceding" > >- section 3.4.1: "any number of instance" -> "any number of instances" > >- section 3.4.1: "dCDN i.e." -> "dCDN, i.e., " > >- section 3.4.1: "MUST list all the fields name whose" -> > "MUST contain all the field names whose" > >- section 3.4.1: "The fields name" -> "The field names" > >- section 3.4.1: "cs- method" -> "cs-method" > >- section 3.4.1: "sc- total-bytes" -> "sc-total-bytes" > >- section 4: "each of these CDNI Logging File" -> > "each of these CDNI Logging Files" > >- section 4: "at the uCDN convenience" -> "at the uCDN's convenience" > >- section 4: "as per the present document generating CDNI Logging file" -> > ", as per the present document, generating CDNI Logging >files" > >- section 4: "as per the present document consuming CDNI Logging file" -> > ", as per the present document, consuming CDNI Logging files" > >- section 4: "document ." -> "document." > >- section 4.1.2: "MAY be unable to serve" -> > "MAY indicate its inability to serve" > >- section 4.1.3: "redundancy, CDNI Logging" -> "redundancy. CDNI Logging" > >- section 4.2: "( [RFC2616])" -> "[RFC2616]" > >- section 4.2: "MAY be unable to serve" -> > "MAY indicate its inability to serve" > >- section 6.3: "such as how much bytes of the content has been watched" -> > "such as how many bytes of the content have been watched" > > >_______________________________________________ >CDNi mailing list >CDNi@ietf.org >https://www.ietf.org/mailman/listinfo/cdni From mcaulfie@cisco.com Tue Nov 12 08:02:09 2013 Return-Path: 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 DF9B421E828D for ; Tue, 12 Nov 2013 08:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V1wnCtT0CA8 for ; Tue, 12 Nov 2013 08:02:05 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3885B11E8203 for ; Tue, 12 Nov 2013 08:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15882; q=dns/txt; s=iport; t=1384272125; x=1385481725; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lFDj63mP5yzgw8kCB3ViOLmR/ug1ZRDCXEJjFLlSqRs=; b=aLB7sevki7EdZ+ae6C+cDIEB1CYMkeOTGiKbuRkT7qmb5d1yoy9ZWkJB oPvw5DwBFlqqtP1/WXyg/AwWU7cEVI5uv/4jM0WTWD3239+JwDZ7HJ5TQ K2zZPcvpwrqDc1ViWIcAPZcGpDg60/xRARlKAzhuw3s7C0vPGB3eZFlww M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAI5QglKtJV2Z/2dsb2JhbABagwc4U78fgSoWdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQcnCxQJCAIECgQFCIdzBg2+fo4mBoECMQcGgxqBEQOqGYMmgWkIFyI X-IronPort-AV: E=Sophos;i="4.93,685,1378857600"; d="scan'208";a="283755658" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 12 Nov 2013 16:02:01 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rACG207p007538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 16:02:00 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 10:01:59 -0600 From: "Matt Caulfield (mcaulfie)" To: "Francois Le Faucheur (flefauch)" , "Brandenburg, R. (Ray) van" Thread-Topic: Suggestion for progressing on "Partial Caching"/"Byte Range request" Thread-Index: AQHO3OufLD0EFY7XLEK3yulW5baCi5ohxo2A Date: Tue, 12 Nov 2013 16:01:58 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C921DDF0B59@xmb-aln-x03.cisco.com> References: <89B634B5-60FA-4AE7-A924-B76D86096CC6@cisco.com> <291CC3F9E50E7641901A54E85D0977C6B027F5A1A2@MAILR002.mail.lan> <2779C9F0771F974CAD742BAE6D9904FE639DAC05@PALLENE.office.hd> <291CC3F9E50E7641901A54E85D0977C6B027F5A550@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B027F5A648@MAILR002.mail.lan> <3204FE67-6E32-42ED-AC02-CA45B544F9C5@tno.nl> <6C0BCBC2-19CA-4C80-9657-DCE062835BA2@cisco.com> In-Reply-To: <6C0BCBC2-19CA-4C80-9657-DCE062835BA2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.76.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Suggestion for progressing on "Partial Caching"/"Byte Range request" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:02:10 -0000 I agree with this approach - a new draft with a registry to define the beha= vior of the dCDN w.r.t. partial caching. Ray, I can help with this if you'd like. We can use rate pacing as a templa= te. Regards, Matt -----Original Message----- From: Francois Le Faucheur (flefauch)=20 Sent: Friday, November 08, 2013 8:33 PM To: Brandenburg, R. (Ray) van Cc: cdni@ietf.org; Matt Caulfield (mcaulfie) Subject: Suggestion for progressing on "Partial Caching"/"Byte Range reques= t" Hi Ray and all, Based on a few conversations here in Vancouver on that topic, I think handl= ing of Partial Caching in CDNI would involve: * defining a Capability, so the dCDN can indicate in FCI whether/how it su= pports "Partial Caching" (e.g. dCDN does not support Partial Caching, dCDN = support Partial Caching for all content, dCDN supports Partial Caching on a= per content item/set basis) * defining an additional CDNI Metadata information Element, allowing the u= CDN to tell the dCDN (or a per content item/content sets basis) whether "pa= rtial Caching" is needed (or not) from dCDN when client issues a byte range= request to this content. Something like: o Partial-Caching: dCDN needs to minimise the amount of data requested o= n acquisition - eg by only acquiring the same byte range as requested by en= d-user,=20 o No-Partial-Caching: dCDN is not required to minimise the amount of data= requested on acquisition - ie dCDN behaves whichever way it wants. A possible way to progress this would be to take a similar approach to what= is being done for rate-pacing, ie progress a standalone I-D that focuses o= n this functionality and defines the corresponding use case + overall funct= ionality, and defines the impact and necessary extensions for each of the C= DNI interfaces. Makes sense? Would you be interested in driving that? Matt may be willing to work on that. If other folks are interested in contributing in that effort, let us know. Cheers Francois On 7 Nov 2013, at 20:50, "Brandenburg, R. (Ray) van" wrote: > Hi all, >=20 > I think Kevin raises an interesting point. It's not so much a capability = that you want to check for, it's something you want to mandate from a dCDN,= similar to how a uCDN might mandate other elements of the delivery process= . In that sense, the metadata interface is indeed a more appropriate interf= ace.=20 >=20 > (Now that we're discussing this, do we have to worry about people=20 > arguing that mandating something that has to do with acquisition goes=20 > against the charter which specifies the acquisition interface to be=20 > out of scope? :)) >=20 > Best regards, >=20 > Ray >=20 >> On 6 nov. 2013, at 16:43, "Kevin J Ma" wrote= : >>=20 >> Hi Scott, >>=20 >> My point was that: >>=20 >> wrt to 2), the dCDN can advertise its acquisition protocol capabilities. >> If it says it supports HTTP, it is assumed that it supports all of=20 >> HTTP including range requests, so I see no reason to add an=20 >> additional "Partial Caching" capability flag which essentially says:=20 >> "yes I really do support range requests". If theres a dCDN that=20 >> doesnt support range requests, then it should advertise some type of=20 >> HTTP-lite for its acquisition protocol. That was a well debated use=20 >> case for acquisition protocols, as I recall? >>=20 >> wrt to 1) and 3), the uCDN telling the dCDN how to acquire content is=20 >> a completely separate issue. It is really a metadata issue, not a=20 >> capability issue (given that the capability part should already be=20 >> addressed through the acqusition protocol capability). >>=20 >> If what we are really looking for is a new HTTP-minus-range-gets=20 >> protocol for the registry, and maybe a you-must-propogate-range-gets=20 >> metadata, then that is a different discussion, and I would like to=20 >> clarify that first? >>=20 >> thanx. >>=20 >> -- Kevin J. Ma >>=20 >>> -----Original Message----- >>> From: Scott Leibrand [mailto:sleibrand@llnw.com] >>> Sent: Wednesday, November 06, 2013 2:00 AM >>> To: Kevin J Ma >>> Cc: Jan Seedorf; Francois Le Faucheur (flefauch); Brandenburg, R.=20 >>> (Ray) van; Larry Peterson; cdni@ietf.org; Daryl Malas >>> Subject: Re: Discussing a "Partial Caching" Capability (for=20 >>> byte-range >>> requests) in FCI semantics >>>=20 >>>=20 >>>>> On Nov 5, 2013, at 8:54 PM, Kevin J Ma >>>> wrote: >>>>=20 >>>> I have a couple clarifying questions about the partial caching: >>>>=20 >>>> 1. Is there text somewhere that states that dCDNs MUST only cache=20 >>>> what the client requested? >>>>=20 >>>> Just because the dCDN is capable of partial caching, doesnt mean=20 >>>> that it won't go ahead and ask for the whole file? >>>=20 >>> A uCDN (with a CSP customer with a very large video library) who is=20 >>> doing partial caching themselves needs their dCDNs to do something=20 >>> similar, and only request content that users actually request=20 >>> (modulo some read ahead or whatever). Otherwise, the dCDN's requests=20 >>> blow up the active library on the uCDN's caches, causing them to=20 >>> have to double storage capacity to cache portions of the content no one= is watching. >>>=20 >>> If a dCDN doesn't support the capability to only ask for what they=20 >>> need, the uCDN may be better off serving the content themselves. >>>=20 >>>>=20 >>>> 2. If we assume the dCDN only does partial acquisition requests,=20 >>>> when it receives a partial delivery request, then my question is,=20 >>>> are we concerned that dCDN is incapable of doing range requests? =20 >>>> If so, should that not show up in the acquisition protocol capability? >>>>=20 >>>> It's unclear to me what information the partial caching capability=20 >>>> is actually conveying? >>>=20 >>> I'm not following. Range requests are how partial objects are transferr= ed. >>> If the dCDN doesn't support range requests, we have bigger problems. >>>=20 >>>>=20 >>>> 3. If what we really want is a way for the uCDN to tell the dCDN=20 >>>> whether or not to use partial caching for a given piece of content,=20 >>>> then I would think what we need is a new metadata object, not a new >>> capability? >>>=20 >>> I'm not familiar enough with the spec to know what we need there.=20 >>> But the central requirement is for the uCDN to be able to tell dCDNs=20 >>> to do partial caching for a given CSP's content, and for the uCDN to=20 >>> be able to avoid using any dCDNs that don't support partial caching. >>>=20 >>> -Scott >>>>=20 >>>> thanx. >>>>=20 >>>> -- Kevin J. Ma >>>>=20 >>>>> -----Original Message----- >>>>> From: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] >>>>> Sent: Tuesday, November 05, 2013 12:42 PM >>>>> To: Kevin J Ma; Francois Le Faucheur (flefauch) >>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg >>> (Ray); >>>>> Larry Peterson; cdni@ietf.org; Daryl Malas >>>>> Subject: RE: Discussing a "Partial Caching" Capability (for=20 >>>>> byte-range >>>>> requests) in FCI semantics >>>>>=20 >>>>> Same here, we have not considered this, but sure let's discuss it >>> during >>>>> Thursday's lunch meeting >>>>>=20 >>>>> - Jan >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>>> Sent: Tuesday, November 05, 2013 5:16 PM >>>>>> To: Francois Le Faucheur (flefauch); Jan Seedorf >>>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg >>> (Ray); >>>>>> Larry Peterson; cdni@ietf.org; Daryl Malas >>>>>> Subject: RE: Discussing a "Partial Caching" Capability (for=20 >>>>>> byte-range >>>>>> requests) in FCI semantics >>>>>>=20 >>>>>> i did not consider it, but i am happy to discuss it. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >>>>>> Sent: Tuesday, November 05, 2013 11:12 AM >>>>>> To: Jan Seedorf; Kevin J Ma >>>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg >>> (Ray); >>>>>> Francois Le Faucheur (flefauch); Larry Peterson; cdni@ietf.org;=20 >>>>>> Daryl >>>>> Malas >>>>>> Subject: Discussing a "Partial Caching" Capability (for=20 >>>>>> byte-range >>>>> requests) in >>>>>> FCI semantics >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Jan, Kevin, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Did you consider the following? >>>>>>=20 >>>>>> Can we discuss it in Vancouver? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Tx >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch)=20 >>>>>> wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Scott, Jan, and all, >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 15 Oct 2013, at 11:30, Scott Leibrand wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> This feature (partial object caching) is absolutely a requirement >>> before >>>>> we >>>>>> could think about offloading on-demand video traffic to a dCDN. =20 >>>>>> If >>> the >>>>> dCDN >>>>>> downloads the entire file, that completely ruins the uCDN's=20 >>>>>> efforts to >>>>> do >>>>>> partial caching, and the resulting increase in cache use makes=20 >>>>>> things >>>>> worse >>>>>> than not using a dCDN at all. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Then perhaps it would make sense to include something like=20 >>>>>> "Partial >>>>> Object >>>>>> Caching" in the set of capabilities that can be advertised in the=20 >>>>>> CDNI >>>>> Footprint >>>>>> and Capabilities Advertisement interface (FCI). This would allow=20 >>>>>> the >>>>> uCDN to >>>>>> select a dCDN that supports partial object caching when required=20 >>>>>> (or >>>>> possibly >>>>>> elect to serve itself). >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Jan, >>>>>>=20 >>>>>> Would you mind including this as a candidate in your list so we >>> rememebr >>>>> to >>>>>> make a concious decision about it? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Thanks >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Francois >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -Scott >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van=20 >>>>>> wrote: >>>>>>=20 >>>>>> Hi Ben, >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >>>>>>> Sent: maandag 14 oktober 2013 5:10 >>>>>>> To: Brandenburg, R. (Ray) van >>>>>>> Cc: cdni@ietf.org >>>>>>> Subject: Re: [CDNi] CDNI and byte-range requests >>>>>>>=20 >>>>>>> Ray, >>>>>>>=20 >>>>>>>> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> As I'm not sure whether this should be part of the Redirection >>>>> Interface >>>>>>> document or the Framework document, let me just post this as a >>> general >>>>>>> question to the list: >>>>>>>>=20 >>>>>>>> To my knowledge, the current CDNI documents do not explicitly >>>>> address >>>>>>> the case of HTTP Byte-range requests. Although in most cases=20 >>>>>>> byte- >>>>> range >>>>>>> requests will function just as any other requests, I think there=20 >>>>>>> are >>>>> some >>>>>> cases >>>>>>> where byte-range requests warrant further attention. An example=20 >>>>>>> is >>> the >>>>>>> Redirection interface. If a uCDN asks a dCDN to deliver a=20 >>>>>>> particular >>>>> user >>>>>>> request (containing a byte range), and the dCDN answers=20 >>>>>>> positively, >>>>> can >>>>>> the >>>>>>> uCDN assume that the dCDN accepts any future requests for the=20 >>>>>>> same >>>>> file >>>>>>> with a different byte range? And if that is the case, is this=20 >>>>>>> default >>>>> behavior >>>>>> or >>>>>>> do we need an explicit flag in the inter-CDN redirection request=20 >>>>>>> to >>>>> indicate >>>>>>> the uCDN/dCDN's preference? >>>>>>>>=20 >>>>>>>> To be clear: I don't think we need any new functionality to=20 >>>>>>>> handle >>>>> byte- >>>>>>> range requests, but a few sentences in either the Framework or=20 >>>>>>> the RI document might clear up any future uncertainty. >>>>>>>=20 >>>>>>> I don't see how this is any different to a sequence of non=20 >>>>>>> byte-range requests. >>>>>>>=20 >>>>>>> It will likely depend on the behaviour of the client (and=20 >>>>>>> possibly >>>>> whether >>>>>> the >>>>>>> server closes the connection after each request if that drives a >>>>> different >>>>>>> client behaviour) as to where the client ends up going (uCDN or=20 >>>>>>> dCDN) >>>>>> when >>>>>>> it makes a subsequent request. >>>>>>>=20 >>>>>>> Trying to say anything here may take us down the rat hole of=20 >>>>>>> trying >>> to >>>>>>> describe client behaviour which we don't control. >>>>>>=20 >>>>>> Let me give a practical example: Let's say the uCDN is hosting a=20 >>>>>> 2gb >>> TS >>>>> file. At >>>>>> some point it receives an incoming request for a particular byte=20 >>>>>> range >>>>> within >>>>>> that file, let's say the first 10mb. For some reason the uCDN=20 >>>>>> decides >>>>> that it >>>>>> wants to redirect the request to a dCDN. The dCDN receives the >>> request. >>>>> At >>>>>> that point it has to decide what to do: does it download the full=20 >>>>>> 2gb >>>>> file from >>>>>> the uCDN, or does it download just the first 10mb? Of course it's >>> fully >>>>> up to >>>>>> internal logic in the dCDN to decide what it should do here,=20 >>>>>> however >>> it >>>>> does >>>>>> have an impact on the uCDN as well (potentially unnecessary=20 >>>>>> traffic >>>>> reducing >>>>>> the effectiveness of the inter-CDN redirect). My question is, do=20 >>>>>> we >>> need >>>>> to >>>>>> say anything about this case to help both the dCDN and uCDN in=20 >>>>>> making >>>>> this >>>>>> decision? >>>>>>=20 >>>>>> Ray >>>>>>=20 >>>>>>=20 >>>>>>> Ben >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best regards, >>>>>>>>=20 >>>>>>>> Ray >>>>>>>> This e-mail and its contents are subject to the DISCLAIMER at >>>>>>> http://www.tno.nl/emaildisclaimer >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> CDNi mailing list >>>>>>>> CDNi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>=20 >=20 >=20 >=20 > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u = niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden= , wordt u verzocht dat aan de afzender te melden en het bericht te verwijde= ren. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, d= e wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verb= and houdt met risico's verbonden aan het elektronisch verzenden van bericht= en. >=20 >=20 >=20 > This message may contain information that is not intended for you. If you= are not the addressee or if this message was sent to you by mistake, you a= re requested to inform the sender and delete the message. TNO accepts no li= ability for the content of this e-mail, for the manner in which you use it = and for damage of any kind resulting from the risks inherent to the electro= nic transmission of messages. >=20 From flefauch@cisco.com Tue Nov 12 09:26:57 2013 Return-Path: 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 EAC0621E80B2 for ; Tue, 12 Nov 2013 09:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU+PkOkvQODk for ; Tue, 12 Nov 2013 09:26:50 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B4FD811E80FE for ; Tue, 12 Nov 2013 09:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19034; q=dns/txt; s=iport; t=1384277210; x=1385486810; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZtZC5qIGdIbeEmHSbYH+lsLDZxCrWhMvRarmbe0wnHM=; b=iYmYeByyG6FPlShbFFcvMcKh0rh1QWlNau2Y1XFtd7quEoD11HjiWGMa HQ2zYsKYFNqW74+2y8udEG+1V4AvDgYGhIRreBxbuPzOzVHoT2qvGpV6N Gyp+ncO4NHxW/8U/O1nU+yVaGJk1aN4qQGcqiyzGqswbqUQHv6/iXJfAA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADlkglKtJXG8/2dsb2JhbABagwc4U78WgSoWdIIlAQEBBAEBASREAwQHEAIBCBguJwslAgQOBYgBDb8VBI8sMwcCgx6BEQOYD5IKgyaCKg X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="283791379" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 12 Nov 2013 17:26:25 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rACHQOnZ004089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 17:26:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 11:26:24 -0600 From: "Francois Le Faucheur (flefauch)" To: Kevin J Ma Thread-Topic: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 1] Thread-Index: AQHO38xPeTp9cVgL7Uq31lnySs1Sdw== Date: Tue, 12 Nov 2013 17:26:24 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6B028025C59@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B028025C59@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.195] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 1] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:26:57 -0000 Hi Kevin and all, (as an editor) Thanks very much for this timely and exhaustive review. Please see proposed resolution below for a first batch of comments . On 9 Nov 2013, at 21:04, Kevin J Ma wrote: >=20 > comments: >=20 > - general: There is inconsistency between the use of "End-User" and > "End User", with one stray "end user" and a stray "enduser". > These should be cleaned up for consistency. Converted all occurences to "End User" as defined in RFC 6707. (BTW, also fixed some "User-Agent"/"User Agent" inconsistencies") >=20 > - general: There is an inconsistency with comma usage after "i.e." (vs. > "i.e.,") and "e.g." (vs. "e.g.,"). These should be cleaned > up for consistency. Converted to "i.e.," and "e.g.,". (Just curious: have you published a book before, or just have a rigorous mi= nd? I'm asking because the very few people I have met so far who paid atte= ntion to punctuation after "i.e." had become sensitive to it after going th= rough professionnal edition). >=20 > - general: What does "in future version of this document" mean? Does > it mean a new RFC that obsoletes this RFC? Should these > notes instead refer to a future version of the protocol? > Or should they just state that things are out of scope? Cleaned up to "=85 is/are for further study and outside the scope of this d= ocument." (except in Appendix A - cleaned up to "in future version of the protocol"- = but this Appendix will be removed before publication]. >=20 > - section 1.1: wrt the following statement: >=20 > "we use the word "Log" only for referring to internal CDN > logs and we use the word "Logging" for any inter-CDN information > exchange and processing operations related to CDNI Logging interface.= " >=20 > should use of the lower case "log" and "logging" > throughout the document be interpreted as generic > terms, without distinction for local CDN vs CDNI? > Certain cases seem as though they should be capitalized. > I did not enumerate these in this review. The following sentence was removed altogether: " we use the word "Log" only for referring to internal CDN logs and we use the word "Logging" for any inter-CDN information exchange and processing operations related to CDNI Logging interface." " The defintions were cleaned up to: " Intra-CDN Logging information: logging information generated and collected = within a CDN. The format of the Intra-CDN Logging information may be differ= ent to the format of the CDNI Logging information. CDNI Logging information: logging information exchanged across CDNs using t= he CDNI Logging Interface. Logging information: logging information generated and collected within a C= DN or obtained from another CDN using the CDNI Logging Interface. " The text was cleaned up to use "Intra-CDN Logging information" or "CDNI Log= ging information" or "Logging information" as appropriate. There is only on= e or two occurences where "logging information" was used in non-capitalised= form because it was a generic reference. BTW: I also cleaned up many occurences of inconsistent use of "CDNI Logging= file" instead of "CDNI Logging File". >=20 > - section 2.2.4: I found this clause to be very confusing: Agreed. > "In the case where the log-generating entities have generated during- > generation aggregate logs" >=20 > Perhaps it would be easier to just say: >=20 > "In the case where aggregate logs have been generated" Fixed to : "In the case where aggregate logs have been generated directly by the log-g= enerating entities, " >=20 > - section 3.2: The first sentance notes that Logging Fields and > Records are defined in 1.1. Logging Files are also > defined in 1.1, but the second sentance caused me to > second guess this: >=20 > "As defined in Section 1.1 a CDNI logging field is as an atomic > logging information element and a CDNI Logging Record is a collection > of CDNI Logging Fields containing all logging information > corresponding to a single logging event. This document defines a > third level of structure, the CDNI Logging File, that is a collection > of CDNI Logging Records." >=20 > Perhaps it would be more clear to just say: >=20 > "As defined in Section 1.1: a CDNI logging field is as an atomic > logging information element, a CDNI Logging Record is a collection > of CDNI Logging Fields containing all logging information > corresponding to a single logging event, and a CDNI Logging File > contains is a collection of CDNI Logging Records." Done. Cheers Francois >=20 > - section 3.3: I think we should define a restriction on DIRNAME to be > not COLON (":")? Perhaps even just alphanumberic plus > dash and underscore? This should be enforced by the > IANA reviewer? >=20 > - section 3.3: The DIRVAL should be specified by the reference > document in the CDNI Logging Directive Names registry > (Section 5.1). The BNF should note that. The fact > that the initial directives are defined in this > document is a degenerate case of generic DIRVALs. >=20 > " DIRVAL =3D name>" >=20 > - section 3.3: For any directive with a format defined as NHTABSTRING, > don't we also need to exclude CRLF from the string? >=20 > - section 3.3: For the Record-Type directive, I think it would be more > clear to change: "precede any CDNI Logging Record" -> > "MUST precede all CDNI Logging Records" >=20 > - section 3.3: I think we should define a restriction on FIENAME to be > not HTAB and not CRLF? Perhaps even just alphanumberic > plus dash and underscore? This should be enforced by > the IANA reviewer? >=20 > - section 3.3: It was not clear to me initially, what this sentance is > attempting to say. 3.4 has an example of a logging > record and its list of fields, but it's not the only > possible logging record, it's just the first one > defined. When I first read this, I interpreted it as > all possible logging records are defined in 3.4. >=20 > " The names of the fields, as well as their > possible occurrences, are specified for each type of CDNI > Logging Records in Section 3.4." >=20 > Perhaps it couldbe clarified to say something like: >=20 > " The names of the fields, as well as their > possible occurrences, MUST be specified in the referenced > document of the CDNI Logging Record-types registry (Section > 5.2), for each CDNI Logging Record-Type. This document > defines the names of the fields, as well as their possible > occurrences, for the "cdni_http_request_v1" Record-Type in > Section 3.4.1." >=20 > - section 3.3: Just to clarify, this statement asserts that the file > is "non-corrupted", but makes no guarantee that it is > tamper-proof or tamper-evident (a la MITM attack)? >=20 > " If the > two values are equal, then the received CDNI Logging File MUST > be considered non-corrupted." >=20 > - section 3.4.1: For any field value with a format defined as > NHTABSTRING, don't we also need to exclude CRLF from > the string? >=20 > - section 3.4.1: For protocol, do we want this to be extensible to > HTTP/2.0? Does the normative reference to RFC2616 > restrict this to HTTP/1.0 and HTTP/1.1? >=20 > I had assumed that the v1 in "cdni_http_request_v1" > referred to the Logging Record version, but perhaps > it instead refers to the HTTP version? This is > probably worth clarifying. >=20 > - section 3.4.1: In the sc-total-bytes and sc-entity-bytes field value > descriptions, the parenthetical references to HTTP > headers seems to imply some inherent relationship > between the headers and the status line, which I do > not believe exists, per section 6 of RFC2616. >=20 > " This includes the bytes of the Status-Line (including HTTP > headers)" >=20 > " This does not include the bytes of the Status-Line > (and therefore does not include the bytes of the HTTP headers)". >=20 > I think it would be clearer to say: >=20 > " This includes the bytes of the Status-Line and the bytes > of the HTTP headers" >=20 > " This does not include the bytes of the Status-Line > or the bytes of the HTTP headers". >=20 > - section 3.4.1: For all the fields values whos format is QSTRING, the > field value description should be updated to indicate > that the value is not actually "as received" or "as > it appears in the response", etc., but rather that > value encased in double quotes with any double quotes > in that value escaped by an additional double quote? >=20 > - section 3.4.1: I found the following text odd, in that the normative > statement is that the value must be either something or > nothing, which is somewhat tautological. Should this > just be a MAY since its optional? >=20 > " there MUST be zero, one or any number of instance" >=20 > - section 3.4.1: For the s-sid field, is the only allowable use of > this field for HAS delivery? Or can the field be > used to group requests for any content? If it is > really the latter, this should be clarified. >=20 > " this contains the value of a Session IDentifier > generated by the dCDN for a specific HTTP Adaptive Streaming > (HAS) session" >=20 > - section 3.4.1: Is it really the logging implementation that selects > the fields? That does not sound correct to me? I > would suggest removing: "by the implementation > generating the CDNI Logging File" from this text: >=20 > "The set > of such fields name actually listed in the "Fields" directive is > selected by the implementation generating the CDNI Logging File based > on agreements between the interconnected CDNs established through" >=20 > - section 3.4.1: I would suggestion removing "in that case, " from > this sentance: >=20 > "When such a field name is listed in the "Fields" > directive, the corresponding field value MUST be included in the > Logging Record; in that case, if the value for the field is not > available, this MUST be conveyed via a dash character ("-")." >=20 > - section 3.4.1: Just to clarify, the following text is defining the > MTI fields for dCDNs. >=20 > "A dCDN-side implementation of the CDNI Logging interface MUST support > the ability to include valid values for the following Logging Fields" >=20 > Would it be valid to always put a dash ("-")? Dash > is a valid value, but does not require the dCDN to > actually support parsing/producing any given field. >=20 > - section 3.5: The UUID directive is not QSTRING, its NHTABSTRING, so > can I assume that the double quotes are actually part > of the UUID? Or is this example incorrect? >=20 > " #UUID:"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"" >=20 > - section 4.1: The terms "server-side" and "client-side" essentially > refer to the "dCDN" and "uCDN", respectively, correct? > I think it would be easier to follow if we used "dCDN" > and "uCDN" since client and server are used for other > purposes with other meanings in other parts of the draft. >=20 > - section 4.1.1: What is an "IRI"? Should that be "URI" or "URN"? >=20 > - section 4.1.2: Just to clarify, the "archive document" refers to > past contents of the atom feed, correct? This > section makes no statement about how long old logging > files should be kept for, only how long old atom feed > documents are held for? Should we? >=20 > - section 4.2: Do we have thoughts on future HTTP/2.0 support? Not > that I necessarily think that things like multiplexing > would necessarily be beneficial to log retrieval, but > should we consider the possibility of HTTP/2.0 > obsoleting HTTP/1.1 in a few years? Would we have to > rev the LI RFC at that point? >=20 > " MUST use HTTP v1.1 ( [RFC2616]);" >=20 > - section 5.1: Should we add instructions to the implied expert > reviewer requiring that each specification defining a > new directive contain the same type of information for > each directive as in 3.3 (i.e., format, directive > value, and occurrence)? >=20 > - section 5.2: Should we add instructions to the implied expert > reviewer requiring that each specification defining a > new record-type contain the same type of information > for each field as in 3.4.1 (i.e., field name, format, > field value, and occurrence)? >=20 > - section 5.3: Should the Field Names registry really be a subregistry > under the Record-types registry? Without the scope of > the Record-Type, these field names cannot be used for > any other Record-Type, e.g., "date" and "time" can only > ever be used by cdni_http_request_v1? Or at a minimum, > they must have the exact same meaning? If that is the > intent, then we may want to make that explicit in the > text. >=20 > - section 6.1: I believe this is implying that mutual authentication > SHOULD be used? Should that be made explicit? >=20 > " the dCDN and uCDN to authenticate each other (to ensure they are > transmitting/receiving CDNI Logging File from an authenticated > CDN) >=20 > - section 6.1: Do we want to make an explicit statement about privacy > of End-User information? And possibly an explicit > statement about the acceptability of alternate methods > for ensuring confidentiality of End-User information > (e.g., an IPSec tunnel between CDNs, or physically > secured internal network between two CDNs owned by the > same corporate entity)? >=20 > " the CDNI Logging information to be transmitted with > confidentiality" >=20 > Note: The privacy section (6.3) talks about > anonymization between dCDN and uCDN, however, > this is more about leaking even anonymized data. >=20 > - appendix A: Is this going to be removed? >=20 > nits: >=20 > - section 1.1: "real time" -> "real-time" >=20 > - section 2.1: ", uCDN uses" -> ", the uCDN uses" >=20 > - section 2.1: "delivery operated by" -> "delivery performed by" >=20 > - section 2.1: "non real-time" -> "non-real-time" >=20 > - section 2.1: "to CSP." -> "to the CSP." >=20 > - section 2.1: ", uCDN merges" -> ", the uCDN merges" >=20 > - section 2.1: ". uCDN may also" -> ". the uCDN may also" >=20 > - section 2.1: "on his behalf." -> "on the CSP's behalf." >=20 > - section 2.1: "e.g., dCDN-3" -> "i.e., dCDN-3" >=20 > - section 2.1: "format that are" -> "formats that are" >=20 > - section 2.2: "more or less" -> "more or fewer" >=20 > - section 2.2: "i.e., there may be" -> "e.g., there may be" >=20 > - section 2.2.3: "may require to" -> "may be required to" >=20 > - section 2.2.3: "by every Surrogate" -> "by each Surrogate" >=20 > - section 2.2.3: "hostnames is not" -> "hostnames are not" >=20 > - section 2.2.4: "real time" -> "real-time" >=20 > - section 2.2.5.6.2: "uCDN and dCDN may" -> "the uCDN and dCDN may" >=20 > - section 2.2.5.6.2: "Top 10 of the most" -> "Top 10 most" >=20 > - section 3.2: "CDNI logging field" -> "CDNI Logging Field" >=20 > - section 3.2: "close to intra-CDN logging format" -> > "close to the intra-CDN Log format" >=20 > - section 3.3: "File ." -> "File." >=20 > - section 3.3: "to HTTP request" -> "to HTTP requests" >=20 > - section 3.3: "each type of CDNI Logging Records" -> > "each type of CDNI Logging Record" >=20 > - section 3.4.1: "prededing" -> "preceding" >=20 > - section 3.4.1: "any number of instance" -> "any number of instances" >=20 > - section 3.4.1: "dCDN i.e." -> "dCDN, i.e., " >=20 > - section 3.4.1: "MUST list all the fields name whose" -> > "MUST contain all the field names whose" >=20 > - section 3.4.1: "The fields name" -> "The field names" >=20 > - section 3.4.1: "cs- method" -> "cs-method" >=20 > - section 3.4.1: "sc- total-bytes" -> "sc-total-bytes" >=20 > - section 4: "each of these CDNI Logging File" -> > "each of these CDNI Logging Files" >=20 > - section 4: "at the uCDN convenience" -> "at the uCDN's convenience" >=20 > - section 4: "as per the present document generating CDNI Logging file" -= > > ", as per the present document, generating CDNI Logging files= " >=20 > - section 4: "as per the present document consuming CDNI Logging file" -> > ", as per the present document, consuming CDNI Logging files" >=20 > - section 4: "document ." -> "document." >=20 > - section 4.1.2: "MAY be unable to serve" -> > "MAY indicate its inability to serve" >=20 > - section 4.1.3: "redundancy, CDNI Logging" -> "redundancy. CDNI Logging= " >=20 > - section 4.2: "( [RFC2616])" -> "[RFC2616]" >=20 > - section 4.2: "MAY be unable to serve" -> > "MAY indicate its inability to serve" >=20 > - section 6.3: "such as how much bytes of the content has been watched" -= > > "such as how many bytes of the content have been watched" >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ray.vanbrandenburg@tno.nl Wed Nov 13 06:45:46 2013 Return-Path: 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 C6F1821E8113 for ; Wed, 13 Nov 2013 06:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhV9fr+e1yF6 for ; Wed, 13 Nov 2013 06:45:38 -0800 (PST) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6096D21E80E1 for ; Wed, 13 Nov 2013 06:45:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,693,1378850400"; d="scan'208";a="16753419" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 13 Nov 2013 15:45:27 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.174]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 15:45:27 +0100 From: "Brandenburg, R. (Ray) van" To: "Matt Caulfield (mcaulfie)" , "Francois Le Faucheur (flefauch)" Thread-Topic: Suggestion for progressing on "Partial Caching"/"Byte Range request" Thread-Index: AQHO3Ouh9CUPoLhxbUqmPqkMyqp2tpohtm0AgAGLxqA= Date: Wed, 13 Nov 2013 14:45:26 +0000 Message-ID: References: <89B634B5-60FA-4AE7-A924-B76D86096CC6@cisco.com> <291CC3F9E50E7641901A54E85D0977C6B027F5A1A2@MAILR002.mail.lan> <2779C9F0771F974CAD742BAE6D9904FE639DAC05@PALLENE.office.hd> <291CC3F9E50E7641901A54E85D0977C6B027F5A550@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B027F5A648@MAILR002.mail.lan> <3204FE67-6E32-42ED-AC02-CA45B544F9C5@tno.nl> <6C0BCBC2-19CA-4C80-9657-DCE062835BA2@cisco.com> <166EBB70C264A9479E459B01B1BA6C921DDF0B59@xmb-aln-x03.cisco.com> In-Reply-To: <166EBB70C264A9479E459B01B1BA6C921DDF0B59@xmb-aln-x03.cisco.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "cdni@ietf.org" Subject: Re: [CDNi] Suggestion for progressing on "Partial Caching"/"Byte Range request" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 14:45:48 -0000 Hi Matt, Francois, I agree that a separate document might be the best option at this point. I = can't promise anything time-wise however. I might have some time before the= next meeting in March, but it will probably be early next year. = Matt, if you could help out, that would be great. Cheers, Ray > -----Original Message----- > From: Matt Caulfield (mcaulfie) [mailto:mcaulfie@cisco.com] > Sent: dinsdag 12 november 2013 17:02 > To: Francois Le Faucheur (flefauch); Brandenburg, R. (Ray) van > Cc: cdni@ietf.org > Subject: RE: Suggestion for progressing on "Partial Caching"/"Byte Range > request" > = > I agree with this approach - a new draft with a registry to define the be= havior > of the dCDN w.r.t. partial caching. > = > Ray, I can help with this if you'd like. We can use rate pacing as a temp= late. > = > Regards, > Matt > = > -----Original Message----- > From: Francois Le Faucheur (flefauch) > Sent: Friday, November 08, 2013 8:33 PM > To: Brandenburg, R. (Ray) van > Cc: cdni@ietf.org; Matt Caulfield (mcaulfie) > Subject: Suggestion for progressing on "Partial Caching"/"Byte Range > request" > = > Hi Ray and all, > = > Based on a few conversations here in Vancouver on that topic, I think > handling of Partial Caching in CDNI would involve: > * defining a Capability, so the dCDN can indicate in FCI whether/how > it supports "Partial Caching" (e.g. dCDN does not support Partial Caching, > dCDN support Partial Caching for all content, dCDN supports Partial Cachi= ng > on a per content item/set basis) > * defining an additional CDNI Metadata information Element, > allowing the uCDN to tell the dCDN (or a per content item/content sets ba= sis) > whether "partial Caching" is needed (or not) from dCDN when client issues= a > byte range request to this content. Something like: > o Partial-Caching: dCDN needs to minimise the amount of > data requested on acquisition - eg by only acquiring the same byte range = as > requested by end-user, > o No-Partial-Caching: dCDN is not required to minimise the > amount of data requested on acquisition - ie dCDN behaves whichever way it > wants. > = > A possible way to progress this would be to take a similar approach to wh= at is > being done for rate-pacing, ie progress a standalone I-D that focuses on = this > functionality and defines the corresponding use case + overall functional= ity, > and defines the impact and necessary extensions for each of the CDNI > interfaces. > Makes sense? > = > Would you be interested in driving that? > Matt may be willing to work on that. > = > If other folks are interested in contributing in that effort, let us know. > = > Cheers > = > Francois > = > On 7 Nov 2013, at 20:50, "Brandenburg, R. (Ray) van" > wrote: > = > > Hi all, > > > > I think Kevin raises an interesting point. It's not so much a capabilit= y that > you want to check for, it's something you want to mandate from a dCDN, > similar to how a uCDN might mandate other elements of the delivery > process. In that sense, the metadata interface is indeed a more appropria= te > interface. > > > > (Now that we're discussing this, do we have to worry about people > > arguing that mandating something that has to do with acquisition goes > > against the charter which specifies the acquisition interface to be > > out of scope? :)) > > > > Best regards, > > > > Ray > > > >> On 6 nov. 2013, at 16:43, "Kevin J Ma" > wrote: > >> > >> Hi Scott, > >> > >> My point was that: > >> > >> wrt to 2), the dCDN can advertise its acquisition protocol capabilitie= s. > >> If it says it supports HTTP, it is assumed that it supports all of > >> HTTP including range requests, so I see no reason to add an > >> additional "Partial Caching" capability flag which essentially says: > >> "yes I really do support range requests". If theres a dCDN that > >> doesnt support range requests, then it should advertise some type of > >> HTTP-lite for its acquisition protocol. That was a well debated use > >> case for acquisition protocols, as I recall? > >> > >> wrt to 1) and 3), the uCDN telling the dCDN how to acquire content is > >> a completely separate issue. It is really a metadata issue, not a > >> capability issue (given that the capability part should already be > >> addressed through the acqusition protocol capability). > >> > >> If what we are really looking for is a new HTTP-minus-range-gets > >> protocol for the registry, and maybe a you-must-propogate-range-gets > >> metadata, then that is a different discussion, and I would like to > >> clarify that first? > >> > >> thanx. > >> > >> -- Kevin J. Ma > >> > >>> -----Original Message----- > >>> From: Scott Leibrand [mailto:sleibrand@llnw.com] > >>> Sent: Wednesday, November 06, 2013 2:00 AM > >>> To: Kevin J Ma > >>> Cc: Jan Seedorf; Francois Le Faucheur (flefauch); Brandenburg, R. > >>> (Ray) van; Larry Peterson; cdni@ietf.org; Daryl Malas > >>> Subject: Re: Discussing a "Partial Caching" Capability (for > >>> byte-range > >>> requests) in FCI semantics > >>> > >>> > >>>>> On Nov 5, 2013, at 8:54 PM, Kevin J Ma > > >>>> wrote: > >>>> > >>>> I have a couple clarifying questions about the partial caching: > >>>> > >>>> 1. Is there text somewhere that states that dCDNs MUST only cache > >>>> what the client requested? > >>>> > >>>> Just because the dCDN is capable of partial caching, doesnt mean > >>>> that it won't go ahead and ask for the whole file? > >>> > >>> A uCDN (with a CSP customer with a very large video library) who is > >>> doing partial caching themselves needs their dCDNs to do something > >>> similar, and only request content that users actually request > >>> (modulo some read ahead or whatever). Otherwise, the dCDN's > requests > >>> blow up the active library on the uCDN's caches, causing them to > >>> have to double storage capacity to cache portions of the content no o= ne > is watching. > >>> > >>> If a dCDN doesn't support the capability to only ask for what they > >>> need, the uCDN may be better off serving the content themselves. > >>> > >>>> > >>>> 2. If we assume the dCDN only does partial acquisition requests, > >>>> when it receives a partial delivery request, then my question is, > >>>> are we concerned that dCDN is incapable of doing range requests? > >>>> If so, should that not show up in the acquisition protocol capabilit= y? > >>>> > >>>> It's unclear to me what information the partial caching capability > >>>> is actually conveying? > >>> > >>> I'm not following. Range requests are how partial objects are > transferred. > >>> If the dCDN doesn't support range requests, we have bigger problems. > >>> > >>>> > >>>> 3. If what we really want is a way for the uCDN to tell the dCDN > >>>> whether or not to use partial caching for a given piece of content, > >>>> then I would think what we need is a new metadata object, not a new > >>> capability? > >>> > >>> I'm not familiar enough with the spec to know what we need there. > >>> But the central requirement is for the uCDN to be able to tell dCDNs > >>> to do partial caching for a given CSP's content, and for the uCDN to > >>> be able to avoid using any dCDNs that don't support partial caching. > >>> > >>> -Scott > >>>> > >>>> thanx. > >>>> > >>>> -- Kevin J. Ma > >>>> > >>>>> -----Original Message----- > >>>>> From: Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] > >>>>> Sent: Tuesday, November 05, 2013 12:42 PM > >>>>> To: Kevin J Ma; Francois Le Faucheur (flefauch) > >>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg > >>> (Ray); > >>>>> Larry Peterson; cdni@ietf.org; Daryl Malas > >>>>> Subject: RE: Discussing a "Partial Caching" Capability (for > >>>>> byte-range > >>>>> requests) in FCI semantics > >>>>> > >>>>> Same here, we have not considered this, but sure let's discuss it > >>> during > >>>>> Thursday's lunch meeting > >>>>> > >>>>> - Jan > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > >>>>>> Sent: Tuesday, November 05, 2013 5:16 PM > >>>>>> To: Francois Le Faucheur (flefauch); Jan Seedorf > >>>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg > >>> (Ray); > >>>>>> Larry Peterson; cdni@ietf.org; Daryl Malas > >>>>>> Subject: RE: Discussing a "Partial Caching" Capability (for > >>>>>> byte-range > >>>>>> requests) in FCI semantics > >>>>>> > >>>>>> i did not consider it, but i am happy to discuss it. > >>>>>> > >>>>>> > >>>>>> > >>>>>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > >>>>>> Sent: Tuesday, November 05, 2013 11:12 AM > >>>>>> To: Jan Seedorf; Kevin J Ma > >>>>>> Cc: Scott Leibrand; Brandenburg, R. (Ray) van; R. van Brandenburg > >>> (Ray); > >>>>>> Francois Le Faucheur (flefauch); Larry Peterson; cdni@ietf.org; > >>>>>> Daryl > >>>>> Malas > >>>>>> Subject: Discussing a "Partial Caching" Capability (for > >>>>>> byte-range > >>>>> requests) in > >>>>>> FCI semantics > >>>>>> > >>>>>> > >>>>>> > >>>>>> Jan, Kevin, > >>>>>> > >>>>>> > >>>>>> > >>>>>> Did you consider the following? > >>>>>> > >>>>>> Can we discuss it in Vancouver? > >>>>>> > >>>>>> > >>>>>> > >>>>>> Tx > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 15 Oct 2013, at 13:40, Francois Le Faucheur (flefauch) > >>>>>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Scott, Jan, and all, > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 15 Oct 2013, at 11:30, Scott Leibrand > wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> This feature (partial object caching) is absolutely a requirement > >>> before > >>>>> we > >>>>>> could think about offloading on-demand video traffic to a dCDN. > >>>>>> If > >>> the > >>>>> dCDN > >>>>>> downloads the entire file, that completely ruins the uCDN's > >>>>>> efforts to > >>>>> do > >>>>>> partial caching, and the resulting increase in cache use makes > >>>>>> things > >>>>> worse > >>>>>> than not using a dCDN at all. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Then perhaps it would make sense to include something like > >>>>>> "Partial > >>>>> Object > >>>>>> Caching" in the set of capabilities that can be advertised in the > >>>>>> CDNI > >>>>> Footprint > >>>>>> and Capabilities Advertisement interface (FCI). This would allow > >>>>>> the > >>>>> uCDN to > >>>>>> select a dCDN that supports partial object caching when required > >>>>>> (or > >>>>> possibly > >>>>>> elect to serve itself). > >>>>>> > >>>>>> > >>>>>> > >>>>>> Jan, > >>>>>> > >>>>>> Would you mind including this as a candidate in your list so we > >>> rememebr > >>>>> to > >>>>>> make a concious decision about it? > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> > >>>>>> > >>>>>> Francois > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -Scott > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Tue, Oct 15, 2013 at 2:23 AM, Brandenburg, R. (Ray) van > >>>>>> wrote: > >>>>>> > >>>>>> Hi Ben, > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > >>>>>>> Sent: maandag 14 oktober 2013 5:10 > >>>>>>> To: Brandenburg, R. (Ray) van > >>>>>>> Cc: cdni@ietf.org > >>>>>>> Subject: Re: [CDNi] CDNI and byte-range requests > >>>>>>> > >>>>>>> Ray, > >>>>>>> > >>>>>>>> On 30 Jul 2013, at 12:27, Brandenburg, R. (Ray) van wrote: > >>>>>>>> > >>>>>>>> Hi all, > >>>>>>>> > >>>>>>>> As I'm not sure whether this should be part of the Redirection > >>>>> Interface > >>>>>>> document or the Framework document, let me just post this as a > >>> general > >>>>>>> question to the list: > >>>>>>>> > >>>>>>>> To my knowledge, the current CDNI documents do not explicitly > >>>>> address > >>>>>>> the case of HTTP Byte-range requests. Although in most cases > >>>>>>> byte- > >>>>> range > >>>>>>> requests will function just as any other requests, I think there > >>>>>>> are > >>>>> some > >>>>>> cases > >>>>>>> where byte-range requests warrant further attention. An example > >>>>>>> is > >>> the > >>>>>>> Redirection interface. If a uCDN asks a dCDN to deliver a > >>>>>>> particular > >>>>> user > >>>>>>> request (containing a byte range), and the dCDN answers > >>>>>>> positively, > >>>>> can > >>>>>> the > >>>>>>> uCDN assume that the dCDN accepts any future requests for the > >>>>>>> same > >>>>> file > >>>>>>> with a different byte range? And if that is the case, is this > >>>>>>> default > >>>>> behavior > >>>>>> or > >>>>>>> do we need an explicit flag in the inter-CDN redirection request > >>>>>>> to > >>>>> indicate > >>>>>>> the uCDN/dCDN's preference? > >>>>>>>> > >>>>>>>> To be clear: I don't think we need any new functionality to > >>>>>>>> handle > >>>>> byte- > >>>>>>> range requests, but a few sentences in either the Framework or > >>>>>>> the RI document might clear up any future uncertainty. > >>>>>>> > >>>>>>> I don't see how this is any different to a sequence of non > >>>>>>> byte-range requests. > >>>>>>> > >>>>>>> It will likely depend on the behaviour of the client (and > >>>>>>> possibly > >>>>> whether > >>>>>> the > >>>>>>> server closes the connection after each request if that drives a > >>>>> different > >>>>>>> client behaviour) as to where the client ends up going (uCDN or > >>>>>>> dCDN) > >>>>>> when > >>>>>>> it makes a subsequent request. > >>>>>>> > >>>>>>> Trying to say anything here may take us down the rat hole of > >>>>>>> trying > >>> to > >>>>>>> describe client behaviour which we don't control. > >>>>>> > >>>>>> Let me give a practical example: Let's say the uCDN is hosting a > >>>>>> 2gb > >>> TS > >>>>> file. At > >>>>>> some point it receives an incoming request for a particular byte > >>>>>> range > >>>>> within > >>>>>> that file, let's say the first 10mb. For some reason the uCDN > >>>>>> decides > >>>>> that it > >>>>>> wants to redirect the request to a dCDN. The dCDN receives the > >>> request. > >>>>> At > >>>>>> that point it has to decide what to do: does it download the full > >>>>>> 2gb > >>>>> file from > >>>>>> the uCDN, or does it download just the first 10mb? Of course it's > >>> fully > >>>>> up to > >>>>>> internal logic in the dCDN to decide what it should do here, > >>>>>> however > >>> it > >>>>> does > >>>>>> have an impact on the uCDN as well (potentially unnecessary > >>>>>> traffic > >>>>> reducing > >>>>>> the effectiveness of the inter-CDN redirect). My question is, do > >>>>>> we > >>> need > >>>>> to > >>>>>> say anything about this case to help both the dCDN and uCDN in > >>>>>> making > >>>>> this > >>>>>> decision? > >>>>>> > >>>>>> Ray > >>>>>> > >>>>>> > >>>>>>> Ben > >>>>>>> > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> > >>>>>>>> Ray > >>>>>>>> This e-mail and its contents are subject to the DISCLAIMER at > >>>>>>> http://www.tno.nl/emaildisclaimer > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> CDNi mailing list > >>>>>>>> CDNi@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/cdni > >>>>>> > >>>>>> _______________________________________________ > >>>>>> CDNi mailing list > >>>>>> CDNi@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/cdni > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> CDNi mailing list > >>>>>> CDNi@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/cdni > >>>> > > > > > > > > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien = u niet > de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, > wordt u verzocht dat aan de afzender te melden en het bericht te > verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van > deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke > aard ook, die verband houdt met risico's verbonden aan het elektronisch > verzenden van berichten. > > > > > > > > This message may contain information that is not intended for you. If y= ou > are not the addressee or if this message was sent to you by mistake, you = are > requested to inform the sender and delete the message. TNO accepts no > liability for the content of this e-mail, for the manner in which you use= it and > for damage of any kind resulting from the risks inherent to the electronic > transmission of messages. > > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From flefauch@cisco.com Mon Nov 18 21:39:31 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB761AEE0F for ; Mon, 18 Nov 2013 21:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZOKphl-voSy for ; Mon, 18 Nov 2013 21:39:30 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 56B9C1AEDE9 for ; Mon, 18 Nov 2013 21:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3226; q=dns/txt; s=iport; t=1384839538; x=1386049138; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=GGcla8iPaPDB70qysduACdFS/VS3S5FNVeiqKvsbaDs=; b=kPUW8Gq5ey45de/VOkcbC+DsTLK4gtOiFVFswAR5EP6zQc3g3sP344Te da0BTjAXBMwGXgdi2Wb13Wabql3I13fbaqDSlRfp7k8Z6KtbA1yw+YyOT V/e5WMLVz1UUbXR91Xz9589ftW2RFVlsIJlbKFh3k1rDixxl2AkfNfY/1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANT4ilKtJXG8/2dsb2JhbABZgweBC786gR4WdIIlAQEBBCcTPxIBCBgeQicEDgWIAcImF48kM4MngREDmBCSDYMogio X-IronPort-AV: E=Sophos;i="4.93,727,1378857600"; d="scan'208";a="528417" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-7.cisco.com with ESMTP; 19 Nov 2013 05:38:58 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAJ5cw4B010067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 05:38:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 18 Nov 2013 23:38:57 -0600 From: "Francois Le Faucheur (flefauch)" To: Kevin J Ma Thread-Topic: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 2] Thread-Index: AQHO5OmkVCLFsAqjEUWi7mDgSqnhGw== Date: Tue, 19 Nov 2013 05:38:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.86.200] Content-Type: text/plain; charset="us-ascii" Content-ID: <3A3C20E7F4C80F4296B39206AC89A888@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 2] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 05:39:31 -0000 On 9 Nov 2013, at 21:04, Kevin J Ma wrote: >=20 > - section 3.3: The DIRVAL should be specified by the reference > document in the CDNI Logging Directive Names registry > (Section 5.1). The BNF should note that. The fact > that the initial directives are defined in this > document is a degenerate case of generic DIRVALs. >=20 > " DIRVAL =3D name>" Agreed. This now reads: " DIRNAME =3D DIRVAL =3D " >=20 >=20 > - section 3.3: For the Record-Type directive, I think it would be more > clear to change: "precede any CDNI Logging Record" -> > "MUST precede all CDNI Logging Records" Done. >=20 >=20 > - section 3.3: It was not clear to me initially, what this sentance is > attempting to say. 3.4 has an example of a logging > record and its list of fields, but it's not the only > possible logging record, it's just the first one > defined. When I first read this, I interpreted it as > all possible logging records are defined in 3.4. >=20 > " The names of the fields, as well as their > possible occurrences, are specified for each type of CDNI > Logging Records in Section 3.4." >=20 > Perhaps it couldbe clarified to say something like: >=20 > " The names of the fields, as well as their > possible occurrences, MUST be specified in the referenced > document of the CDNI Logging Record-types registry (Section > 5.2), for each CDNI Logging Record-Type. This document > defines the names of the fields, as well as their possible > occurrences, for the "cdni_http_request_v1" Record-Type in > Section 3.4.1." I tentatively included the following wording: " The names of the fields, as well as their occurrences, MUST comply with the corresponding rules specified in the document referenced in the CDNI Logging Record-types registry (Section 5.2) for the corresponding CDNI Logging Record-Type. " The objective is to stick to "MUST" statements conditioning the implementat= ion (as opposed to a "MUST" statement pharsed more as a defining the IETF p= rocess for defining new record-types in the future).=20 Let me know if that works for you. If you feel it is really worth stating that a future spec defining a new re= cord-type needs to specify its fields/occurences, then we could perhaps add= a note this as part of the an IANA instructions for the corresponding regi= stry (ie IANA MUST ensure that there is such a spec before allocating a new= value in the registry). Personally I feel it is not necessary, but won't o= bject adding such as statement. Francois From kevin.ma@azukisystems.com Mon Nov 18 21:47:34 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBCD1AD94A for ; Mon, 18 Nov 2013 21:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRtclEFnnprr for ; Mon, 18 Nov 2013 21:47:32 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id A934C1AD8F6 for ; Mon, 18 Nov 2013 21:47:32 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B6D71416AAD; Tue, 19 Nov 2013 00:47:26 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1CFF7416919; Tue, 19 Nov 2013 00:47:26 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Tue, 19 Nov 2013 00:47:25 -0500 From: Kevin J Ma To: "Francois Le Faucheur (flefauch)" Date: Tue, 19 Nov 2013 00:47:24 -0500 Thread-Topic: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 2] Thread-Index: AQHO5OmkVCLFsAqjEUWi7mDgSqnhG5osCwxg Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C768D4BB@MAILR002.mail.lan> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 2] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 05:47:34 -0000 inline: > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Tuesday, November 19, 2013 12:39 AM > To: Kevin J Ma > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org > Subject: Re: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 2] >=20 >=20 > On 9 Nov 2013, at 21:04, Kevin J Ma wrote: > > > > - section 3.3: The DIRVAL should be specified by the reference > > document in the CDNI Logging Directive Names registry > > (Section 5.1). The BNF should note that. The fact > > that the initial directives are defined in this > > document is a degenerate case of generic DIRVALs. > > > > " DIRVAL =3D > name>" >=20 > Agreed. > This now reads: > " > DIRNAME =3D Logging Directive Names registry (Section 5.1)> >=20 > DIRVAL =3D in the CDNI Logging Directive Names registry (Section 5.1) for the > corresponding DIRNAME> > " >=20 > > > > > > - section 3.3: For the Record-Type directive, I think it would be more > > clear to change: "precede any CDNI Logging Record" -> > > "MUST precede all CDNI Logging Records" >=20 > Done. >=20 > > > > > > - section 3.3: It was not clear to me initially, what this sentance is > > attempting to say. 3.4 has an example of a logging > > record and its list of fields, but it's not the only > > possible logging record, it's just the first one > > defined. When I first read this, I interpreted it as > > all possible logging records are defined in 3.4. > > > > " The names of the fields, as well as their > > possible occurrences, are specified for each type of CDNI > > Logging Records in Section 3.4." > > > > Perhaps it couldbe clarified to say something like: > > > > " The names of the fields, as well as their > > possible occurrences, MUST be specified in the referenced > > document of the CDNI Logging Record-types registry (Section > > 5.2), for each CDNI Logging Record-Type. This document > > defines the names of the fields, as well as their possible > > occurrences, for the "cdni_http_request_v1" Record-Type in > > Section 3.4.1." >=20 > I tentatively included the following wording: > " > The names of the fields, as well as their > occurrences, MUST comply with the corresponding rules specified > in the document referenced in the CDNI Logging Record-types > registry (Section 5.2) for the corresponding CDNI Logging > Record-Type. > " > The objective is to stick to "MUST" statements conditioning the > implementation (as opposed to a "MUST" statement pharsed more as a > defining the IETF process for defining new record-types in the future). > Let me know if that works for you. Works for me. > If you feel it is really worth stating that a future spec defining a new > record-type needs to specify its fields/occurences, then we could perhaps > add a note this as part of the an IANA instructions for the corresponding > registry (ie IANA MUST ensure that there is such a spec before allocating > a new value in the registry). Personally I feel it is not necessary, but > won't object adding such as statement. I had another comment further down that makes this suggestion for adding some text to the IANA section. That's probably the best place for it. thanx. -- Kevin J. Ma =20 > Francois >=20 From ben@niven-jenkins.co.uk Wed Nov 20 03:46:10 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275821ADBFF; Wed, 20 Nov 2013 03:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vlsqe0AtTpKN; Wed, 20 Nov 2013 03:46:07 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7431AD73F; Wed, 20 Nov 2013 03:46:07 -0800 (PST) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Vj6EK-0003Qs-9n; Wed, 20 Nov 2013 11:46:00 +0000 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Nov 2013 11:45:57 +0000 Message-Id: <474EB269-5747-43A8-89AE-F226A7B73A7E@niven-jenkins.co.uk> To: rtg-ads@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: rtg-dir@ietf.org, cdni@ietf.org, draft-ietf-cdni-requirements.all@tools.ietf.org Subject: [CDNi] RtgDir review: draft-ietf-cdni-requirements-12 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 11:46:10 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-cdni-requirements-12.txt=20 Reviewer: Ben Niven-Jenkins Review Date: 20 November 2013 IETF LC End Date: 26 November 2013=20 Intended Status: Informational Summary: No issues found. This document is ready for publication. The document is well written and the requirements are individually = labelled and assigned a relative priority (high/medium/low). Major issues: None Minor issues: None Nits: Some acronyms are not expanded before first usage, e.g. CSP in the = introduction. CI-11 seems to have an extraneous '>' on the end of the first line. Ben From kleung@cisco.com Wed Nov 20 09:45:01 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A371AE4F1; Wed, 20 Nov 2013 09:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QmyCKb10Vcb; Wed, 20 Nov 2013 09:44:59 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 31B001AE4E3; Wed, 20 Nov 2013 09:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1888; q=dns/txt; s=iport; t=1384969493; x=1386179093; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Q1pQp15dj5R+lGqmfqoiGWpnaPcy6LU3OVXIfOVY290=; b=cklbbaG39mfPaZbnGwtqg/Gi1lGviuTKVVmFKD2s8MLhE7SMd9MfMh3s C2dszParHcgImN5qhwpITE0BpE7laQV0CFZmN167fvjcwtwemGTYFa2CG iT2k6WxgUyZtjAGh5SwglpAbUFlbxvB3wmXaromrVhe5R+IcvQ4h2NTvL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAP/zjFKtJV2Z/2dsb2JhbABZgwc4U71tgRoWdIIlAQEBBAEBATc0AgkMBAIBCBEDAQEBCxQJBycLFAkIAgQBDQUIAYd4DcB6F48mMQIFBoMagRIDqh+DKIIq X-IronPort-AV: E=Sophos;i="4.93,738,1378857600"; d="scan'208";a="974476" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 20 Nov 2013 17:44:52 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAKHiqXf003905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 17:44:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 11:44:52 -0600 From: "Kent Leung (kleung)" To: Ben Niven-Jenkins , "rtg-ads@tools.ietf.org" Thread-Topic: [CDNi] RtgDir review: draft-ietf-cdni-requirements-12 Thread-Index: AQHO5eYa1bqj9TDFj06Dc5TerDpuVZouX/VQ Date: Wed, 20 Nov 2013 17:44:51 +0000 Message-ID: References: <474EB269-5747-43A8-89AE-F226A7B73A7E@niven-jenkins.co.uk> In-Reply-To: <474EB269-5747-43A8-89AE-F226A7B73A7E@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.100.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "cdni@ietf.org" , "draft-ietf-cdni-requirements.all@tools.ietf.org" Subject: Re: [CDNi] RtgDir review: draft-ietf-cdni-requirements-12 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:45:01 -0000 Hi Ben. Thank you for the review. The two items in the "Nits" will be fixed= in the next version. Kent -----Original Message----- From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: Wednesday, November 20, 2013 3:46 AM To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; cdni@ietf.org; draft-ietf-cdni-requirements.all@tools= .ietf.org Subject: [CDNi] RtgDir review: draft-ietf-cdni-requirements-12 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-cdni-requirements-12.txt=20 Reviewer: Ben Niven-Jenkins Review Date: 20 November 2013 IETF LC End Date: 26 November 2013=20 Intended Status: Informational Summary: No issues found. This document is ready for publication. The document is well written and the requirements are individually labelled= and assigned a relative priority (high/medium/low). Major issues: None Minor issues: None Nits: Some acronyms are not expanded before first usage, e.g. CSP in the introduc= tion. CI-11 seems to have an extraneous '>' on the end of the first line. Ben _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From iesg-secretary@ietf.org Fri Nov 22 10:11:47 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744981AD959; Fri, 22 Nov 2013 10:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZOWxcIdKsXT; Fri, 22 Nov 2013 10:11:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2A41ADBE5; Fri, 22 Nov 2013 10:11:40 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131122181140.16629.15734.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 10:11:40 -0800 Cc: cdni WG Subject: [CDNi] WG Review: Content Delivery Networks Interconnection (cdni) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:11:47 -0000 The Content Delivery Networks Interconnection (cdni) working group in the Transport Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-02. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ Current Status: Active WG Chairs: Daryl Malas Francois Le Faucheur Assigned Area Director: Spencer Dawkins Mailing list Address: cdni@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/cdni Archive: http://www.ietf.org/mail-archive/web/cdni/ Charter: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A specification of the "CDNI Request Routing Redirection interface". This interface will allow an upstream CDN Request Routing system to obtain from the downstream CDN the information necessary to perform request redirection. It is actually a logical bundling of two separate but related interfaces: * Footprint & Capability Advertisement interface: Asynchronous operations to exchange routing information (e.g., the network footprint and capabilities served by a given CDN) that enables CDN selection for subsequent user requests; and * Request Routing Redirection interface: Synchronous operations to select a delivery CDN (surrogate) for a given user request. - A specification of the "CDNI Metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI Logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI Control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. - A specification for "CDNI URI Signing". This document will specify a mechanism that allows interconnected CDNs to support access control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI Metadata interface, CDNI Logging interface). The WG will discuss and address the security, management and operational issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF, if and where appropriate. Milestones: Done - Submit CDNI problem statement to IESG as Informational Done - Submit CDNI use cases to IESG as Informational Sep 2013 - Submit CDNI requirements to IESG as Informational Dec 2013 - Submit CDNI framework to IESG as Informational Dec 2013 - Submit specification of the CDNI Logging interface to IESG as Proposed Standard Dec 2013 - Submit specification of the CDNI Metadata interface to IESG as Proposed Standard Apr 2014 - Submit specification of the CDNI Control interface to IESG as proposed Standard Apr 2014 - Submit specification of the CDNI Request Routing Redirection interface to IESG as Proposed Standard Sep 2014 - Submit specification of the CDNI Footprint & Capabilities Advertisement interface to IESG as Proposed Standard Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Proposed Standard Oct 2014 - Recharter or dissolve From internet-drafts@ietf.org Mon Nov 25 08:14:37 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6B81ADF9F; Mon, 25 Nov 2013 08:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gpIzOTuAJqC; Mon, 25 Nov 2013 08:14:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B5F1ADF7B; Mon, 25 Nov 2013 08:14:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131125161436.14041.97394.idtracker@ietfa.amsl.com> Date: Mon, 25 Nov 2013 08:14:36 -0800 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-framework-07.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 16:14:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Framework for CDN Interconnection Author(s) : Larry Peterson Bruce Davie Filename : draft-ietf-cdni-framework-07.txt Pages : 52 Date : 2013-11-25 Abstract: This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. It obsoletes RFC 3466. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-framework-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-framework-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Nov 26 10:12:16 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3881ADFD9; Tue, 26 Nov 2013 10:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THSy7Wo_HUZx; Tue, 26 Nov 2013 10:12:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE38A1ADFCA; Tue, 26 Nov 2013 10:12:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131126181214.22383.70259.idtracker@ietfa.amsl.com> Date: Tue, 26 Nov 2013 10:12:14 -0800 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-13.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 18:12:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Requ= irements Author(s) : Kent Leung Yiu Lee Filename : draft-ietf-cdni-requirements-13.txt Pages : 24 Date : 2013-11-26 Abstract: Content Delivery Networks (CDNs) are frequently used for content delivery. As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers and Enterprise Service Providers are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-requirements-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iuniana.oprescu@orange.com Wed Nov 27 15:16:02 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6225B1ADF7C for ; Wed, 27 Nov 2013 15:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM2PakDd5oV6 for ; Wed, 27 Nov 2013 15:15:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0E91ADF63 for ; Wed, 27 Nov 2013 15:15:59 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 76BAD2AC752 for ; Thu, 28 Nov 2013 00:15:57 +0100 (CET) Received: from pmexch31.intranet-paris.francetelecom.fr (unknown [10.100.76.21]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 5FCE2180088 for ; Thu, 28 Nov 2013 00:15:57 +0100 (CET) Received: from PMEXCB1D.intranet-paris.francetelecom.fr ([10.100.76.11]) by pmexch31.intranet-paris.francetelecom.fr ([10.100.76.21]) with mapi; Thu, 28 Nov 2013 00:15:57 +0100 From: To: "" Date: Thu, 28 Nov 2013 00:15:56 +0100 Thread-Topic: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 3] Thread-Index: Ac7rxqAo1NesueLfQLWG1XTClADZEA== Message-ID: <18796_1385594157_52967D2D_18796_1711_1_8F0D2F5E4AAB7249BC7339A3E944DEDD226FA2CEF8@PMEXCB1D.intranet-paris.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615 Subject: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 3] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 23:16:02 -0000 Hey Kevin and all, I guess I should thank you for this extensive review of the draft. I suppos= e you like Daryl more than me, because this is making his life easier but i= s giving Fran=E7ois and me more work. :) =20 I did take into account your comments until somewhere in the middle of sect= ion 3.4.1 and did the editorial nits. See below: =20 - section 3.3: I think we should define a restriction on DIRNAME to be not COLON (":")? Perhaps even just alphanumberic plus dash and underscore? This should be enforced by the IANA reviewer? [IO] You are definitely right about excluding ":". I suggest to add the fol= lowing paragraph in section 5.1: The IANA is requested to create a new registry, CDNI Logging Directive Name= s. A Directive Name is an alphanumeric character string with the additional= characters "-" and "_" that can be optionally used. [IO] In 3.1 Rules, we add: ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z ALPHANUM =3D ALPHA / DIGIT DIRNAME =3D ALPHANUM 0*1( "-" / "_" ) *ALPHANUM [IO] Is this DIRNAME too constrained now? =20 - section 3.3: The DIRVAL should be specified by the reference document in the CDNI Logging Directive Names registry (Section 5.1). The BNF should note that. The fact that the initial directives are defined in this document is a degenerate case of generic DIRVALs. " DIRVAL =3D " [IO] Do you want to specify a directive value for each directive in the ABN= F and then have them as alternatives enumerated in the generic DIRVAL rule? DIRVAL-Version =3D "CDNI" "/" 1*DIGIT "." 1*DIGIT DIRVAL-UUID =3D NHTABSTRING DIRVAL-Claimed-Origin =3D host DIRVAL-Verified-Origin =3D host DIRVAL-Record-Type =3D NHTABSTRING DIRVAL-Fields =3D FIENAME * DIRVAL-Integrity-Hash =3D 32HEXDIG DIRVAL =3D DRIVAL-Version / DIRVAL-UUID / DIRVAL-Claimed-Origin / DIRVAL-Ve= rified-Origin /DIRVAL-Record-Type / DIRVAL-Fields / DIRVAL-Integrity-Hash =20 - section 3.3: For any directive with a format defined as NHTABSTRING, don't we also need to exclude CRLF from the string? [IO] Yes, I think it's more precise to exclude HTAB and CRLF. So in 3.1 NHT= ABSTRING =3D *NHTAB; where NHTAB =3D . - section 3.3: For the Record-Type directive, I think it would be more clear to change: "precede any CDNI Logging Record" -> "MUST precede all CDNI Logging Records" [IO] OK. The last phrase in Record-Type becomes "The first instance of this directive MUST precede a Fields directive and MUST precede all CDNI Logging Records." - section 3.3: I think we should define a restriction on FIENAME to be not HTAB and not CRLF? Perhaps even just alphanumberic plus dash and underscore? This should be enforced by the IANA reviewer? [IO] I think excluding HTAB and CRLF would be ok in theory. I think alphanu= meric plus "-" and "_" is maybe just too rigid? =20 - section 3.3: It was not clear to me initially, what this sentance is attempting to say. 3.4 has an example of a logging record and its list of fields, but it's not the only possible logging record, it's just the first one defined. When I first read this, I interpreted it as all possible logging records are defined in 3.4. " The names of the fields, as well as their possible occurrences, are specified for each type of CDNI Logging Records in Section 3.4." Perhaps it couldbe clarified to say something like: " The names of the fields, as well as their possible occurrences, MUST be specified in the referenced document of the CDNI Logging Record-types registry (Section 5.2), for each CDNI Logging Record-Type. This document defines the names of the fields, as well as their possible occurrences, for the "cdni_http_request_v1" Record-Type in Section 3.4.1." [IO] Done by Fran=E7ois. - section 3.3: Just to clarify, this statement asserts that the file is "non-corrupted", but makes no guarantee that it is tamper-proof or tamper-evident (a la MITM attack)? " If the two values are equal, then the received CDNI Logging File MUST be considered non-corrupted." [IO] That is correct. Remember the long discussions we had about non-repudi= ation? In the end, I think the general idea was that authentication and con= fidentiality for the logging files are handled by using HTTPS in the ATOM p= rotocol. - section 3.4.1: For any field value with a format defined as NHTABSTRING, don't we also need to exclude CRLF from the string? [IO] Done. - section 3.4.1: For protocol, do we want this to be extensible to HTTP/2.0? Does the normative reference to RFC2616 restrict this to HTTP/1.0 and HTTP/1.1? I had assumed that the v1 in "cdni_http_request_v1" referred to the Logging Record version, but perhaps it instead refers to the HTTP version? This is probably worth clarifying. [IO] Added the following to the description of Record-Type: "Note that the = cdni_http_request_v1 Record-Type directive refers strictly to the set of Lo= gging Records encompassed by the current version of this document. At the t= ime of publishing, it includes HTTP/1.0 and HTTP/1.1 requests as specified = in RFC 2616". - section 3.4.1: In the sc-total-bytes and sc-entity-bytes field value descriptions, the parenthetical references to HTTP headers seems to imply some inherent relationship between the headers and the status line, which I do not believe exists, per section 6 of RFC2616. " This includes the bytes of the Status-Line (including HTTP headers)" " This does not include the bytes of the Status-Line (and therefore does not include the bytes of the HTTP headers)". I think it would be clearer to say: " This includes the bytes of the Status-Line and the bytes of the HTTP headers" " This does not include the bytes of the Status-Line or the bytes of the HTTP headers". [IO] Done. - section 3.4.1: For all the fields values whos format is QSTRING, the field value description should be updated to indicate that the value is not actually "as received" or "as it appears in the response", etc., but rather that value encased in double quotes with any double quotes in that value escaped by an additional double quote? - section 3.4.1: I found the following text odd, in that the normative statement is that the value must be either something or nothing, which is somewhat tautological. Should this just be a MAY since its optional? " there MUST be zero, one or any number of instance" - section 3.4.1: For the s-sid field, is the only allowable use of this field for HAS delivery? Or can the field be used to group requests for any content? If it is really the latter, this should be clarified. " this contains the value of a Session IDentifier generated by the dCDN for a specific HTTP Adaptive Streaming (HAS) session" - section 3.4.1: Is it really the logging implementation that selects the fields? That does not sound correct to me? I would suggest removing: "by the implementation generating the CDNI Logging File" from this text: "The set of such fields name actually listed in the "Fields" directive is selected by the implementation generating the CDNI Logging File based on agreements between the interconnected CDNs established through" - section 3.4.1: I would suggestion removing "in that case, " from this sentance: "When such a field name is listed in the "Fields" directive, the corresponding field value MUST be included in the Logging Record; in that case, if the value for the field is not available, this MUST be conveyed via a dash character ("-")." - section 3.4.1: Just to clarify, the following text is defining the MTI fields for dCDNs. "A dCDN-side implementation of the CDNI Logging interface MUST support the ability to include valid values for the following Logging Fields" Would it be valid to always put a dash ("-")? Dash is a valid value, but does not require the dCDN to actually support parsing/producing any given field. - section 3.5: The UUID directive is not QSTRING, its NHTABSTRING, so can I assume that the double quotes are actually part of the UUID? Or is this example incorrect? " #UUID:"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"" - section 4.1: The terms "server-side" and "client-side" essentially refer to the "dCDN" and "uCDN", respectively, correct? I think it would be easier to follow if we used "dCDN" and "uCDN" since client and server are used for other purposes with other meanings in other parts of the draft. - section 4.1.1: What is an "IRI"? Should that be "URI" or "URN"? - section 4.1.2: Just to clarify, the "archive document" refers to past contents of the atom feed, correct? This section makes no statement about how long old logging files should be kept for, only how long old atom feed documents are held for? Should we? - section 4.2: Do we have thoughts on future HTTP/2.0 support? Not that I necessarily think that things like multiplexing would necessarily be beneficial to log retrieval, but should we consider the possibility of HTTP/2.0 obsoleting HTTP/1.1 in a few years? Would we have to rev the LI RFC at that point? " MUST use HTTP v1.1 ( [RFC2616]);" - section 5.1: Should we add instructions to the implied expert reviewer requiring that each specification defining a new directive contain the same type of information for each directive as in 3.3 (i.e., format, directive value, and occurrence)? - section 5.2: Should we add instructions to the implied expert reviewer requiring that each specification defining a new record-type contain the same type of information for each field as in 3.4.1 (i.e., field name, format, field value, and occurrence)? - section 5.3: Should the Field Names registry really be a subregistry under the Record-types registry? Without the scope of the Record-Type, these field names cannot be used for any other Record-Type, e.g., "date" and "time" can only ever be used by cdni_http_request_v1? Or at a minimum, they must have the exact same meaning? If that is the intent, then we may want to make that explicit in the text. - section 6.1: I believe this is implying that mutual authentication SHOULD be used? Should that be made explicit? " the dCDN and uCDN to authenticate each other (to ensure they are transmitting/receiving CDNI Logging File from an authenticated CDN) - section 6.1: Do we want to make an explicit statement about privacy of End-User information? And possibly an explicit statement about the acceptability of alternate methods for ensuring confidentiality of End-User information (e.g., an IPSec tunnel between CDNs, or physically secured internal network between two CDNs owned by the same corporate entity)? " the CDNI Logging information to be transmitted with confidentiality" Note: The privacy section (6.3) talks about anonymization between dCDN and uCDN, however, this is more about leaking even anonymized data. =20 =20 =20 - appendix A: Is this going to be removed? [IO] From what I hear, yes. Do you want to keep it? :) nits: - section 1.1: "real time" -> "real-time" - section 2.1: ", uCDN uses" -> ", the uCDN uses" - section 2.1: "delivery operated by" -> "delivery performed by" - section 2.1: "non real-time" -> "non-real-time" - section 2.1: "to CSP." -> "to the CSP." - section 2.1: ", uCDN merges" -> ", the uCDN merges" - section 2.1: ". uCDN may also" -> ". the uCDN may also" - section 2.1: "on his behalf." -> "on the CSP's behalf." - section 2.1: "e.g., dCDN-3" -> "i.e., dCDN-3" - section 2.1: "format that are" -> "formats that are" - section 2.2: "more or less" -> "more or fewer" - section 2.2: "i.e., there may be" -> "e.g., there may be" - section 2.2.3: "may require to" -> "may be required to" - section 2.2.3: "by every Surrogate" -> "by each Surrogate" - section 2.2.3: "hostnames is not" -> "hostnames are not" - section 2.2.4: "real time" -> "real-time" - section 2.2.5.6.2: "uCDN and dCDN may" -> "the uCDN and dCDN may" - section 2.2.5.6.2: "Top 10 of the most" -> "Top 10 most" - section 3.2: "CDNI logging field" -> "CDNI Logging Field" - section 3.2: "close to intra-CDN logging format" -> "close to the intra-CDN Log format" - section 3.3: "File ." -> "File." - section 3.3: "to HTTP request" -> "to HTTP requests" - section 3.3: "each type of CDNI Logging Records" -> "each type of CDNI Logging Record" - section 3.4.1: "prededing" -> "preceding" - section 3.4.1: "any number of instance" -> "any number of instances" - section 3.4.1: "dCDN i.e." -> "dCDN, i.e., " - section 3.4.1: "MUST list all the fields name whose" -> "MUST contain all the field names whose" - section 3.4.1: "The fields name" -> "The field names" - section 3.4.1: "cs- method" -> "cs-method" - section 3.4.1: "sc- total-bytes" -> "sc-total-bytes" - section 4: "each of these CDNI Logging File" -> "each of these CDNI Logging Files" - section 4: "at the uCDN convenience" -> "at the uCDN's convenience" - section 4: "as per the present document generating CDNI Logging file" -> ", as per the present document, generating CDNI Logging files" - section 4: "as per the present document consuming CDNI Logging file" -> ", as per the present document, consuming CDNI Logging files" - section 4: "document ." -> "document." - section 4.1.2: "MAY be unable to serve" -> "MAY indicate its inability to serve" - section 4.1.3: "redundancy, CDNI Logging" -> "redundancy. CDNI Logging" - section 4.2: "( [RFC2616])" -> "[RFC2616]" - section 4.2: "MAY be unable to serve" -> "MAY indicate its inability to serve" - section 6.3: "such as how much bytes of the content has been watched" -> "such as how many bytes of the content have been watched" [IO] Nits are done. =20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From kevin.ma@azukisystems.com Wed Nov 27 16:01:53 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A241ADFF2 for ; Wed, 27 Nov 2013 16:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nA6CLBp_74Zy for ; Wed, 27 Nov 2013 16:01:50 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4A36D1A1EF9 for ; Wed, 27 Nov 2013 16:01:50 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 90EAF7AEBA3; Wed, 27 Nov 2013 19:01:49 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 85D2B7AFDA9; Wed, 27 Nov 2013 19:01:45 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Wed, 27 Nov 2013 19:01:45 -0500 From: Kevin J Ma To: "iuniana.oprescu@orange.com" , "" Date: Wed, 27 Nov 2013 19:01:43 -0500 Thread-Topic: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 3] Thread-Index: Ac7rxqAo1NesueLfQLWG1XTClADZEAAAy2wA Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FB25C@MAILR002.mail.lan> References: <18796_1385594157_52967D2D_18796_1711_1_8F0D2F5E4AAB7249BC7339A3E944DEDD226FA2CEF8@PMEXCB1D.intranet-paris.francetelecom.fr> In-Reply-To: <18796_1385594157_52967D2D_18796_1711_1_8F0D2F5E4AAB7249BC7339A3E944DEDD226FA2CEF8@PMEXCB1D.intranet-paris.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 3] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2013 00:01:53 -0000 Hi Iuniana, My goal is your unequivocal success in pre-empting Daryl. ;-P > [IO] Is this DIRNAME too constrained now? I was primarily concerned with the colon. I don't feel strongly about the alphanumeric thing. > [IO] I think excluding HTAB and CRLF would be ok in theory. I think > alphanumeric plus "-" and "_" is maybe just too rigid? Same here. My primary concern is the CRLF > " DIRVAL =3D = " > > [IO] Do you want to specify a directive value for each directive in the > ABNF and then have them as alternatives enumerated in the generic DIRVAL > rule? I was actually just thinking that the text be changed to something like: " DIRVAL =3D " to match the DIRNAME definition " DIRNAME =3D any CDNI Logging Directive name registered in the CDNI Logging Directive Names registry (Section 5.1)." > - appendix A: Is this going to be removed? > > [IO] From what I hear, yes. Do you want to keep it? :) Definitely not. But, I did not bother to review it, so if it ends up staying, I need to go back and look it over. thanx. -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of > iuniana.oprescu@orange.com > Sent: Wednesday, November 27, 2013 6:16 PM > To: > Subject: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 3] > > Hey Kevin and all, > > I guess I should thank you for this extensive review of the draft. I > suppose you like Daryl more than me, because this is making his life > easier but is giving Fran=E7ois and me more work. :) > > > > I did take into account your comments until somewhere in the middle of > section 3.4.1 and did the editorial nits. See below: > > > > - section 3.3: I think we should define a restriction on DIRNAME to be > > not COLON (":")? Perhaps even just alphanumberic plus > > dash and underscore? This should be enforced by the > > IANA reviewer? > > [IO] You are definitely right about excluding ":". I suggest to add the > following paragraph in section 5.1: > > The IANA is requested to create a new registry, CDNI Logging Directive > Names. A Directive Name is an alphanumeric character string with the > additional characters "-" and "_" that can be optionally used. > > [IO] In 3.1 Rules, we add: > > ALPHA =3D %x41-5A / %x61-7A ; A-Z / a-z > > ALPHANUM =3D ALPHA / DIGIT > > DIRNAME =3D ALPHANUM 0*1( "-" / "_" ) *ALPHANUM > > [IO] Is this DIRNAME too constrained now? > > > > - section 3.3: The DIRVAL should be specified by the reference > > document in the CDNI Logging Directive Names registry > > (Section 5.1). The BNF should note that. The fact > > that the initial directives are defined in this > > document is a degenerate case of generic DIRVALs. > > " DIRVAL =3D > name>" > > [IO] Do you want to specify a directive value for each directive in the > ABNF and then have them as alternatives enumerated in the generic DIRVAL > rule? > > DIRVAL-Version =3D "CDNI" "/" 1*DIGIT "." 1*DIGIT > > DIRVAL-UUID =3D NHTABSTRING > > DIRVAL-Claimed-Origin =3D host > > DIRVAL-Verified-Origin =3D host > > DIRVAL-Record-Type =3D NHTABSTRING > > DIRVAL-Fields =3D FIENAME * > > DIRVAL-Integrity-Hash =3D 32HEXDIG > > DIRVAL =3D DRIVAL-Version / DIRVAL-UUID / DIRVAL-Claimed-Origin / DIRVAL- > Verified-Origin /DIRVAL-Record-Type / DIRVAL-Fields / DIRVAL-Integrity- > Hash > > > > - section 3.3: For any directive with a format defined as NHTABSTRING, > > don't we also need to exclude CRLF from the string? > > [IO] Yes, I think it's more precise to exclude HTAB and CRLF. So in 3.1 > NHTABSTRING =3D *NHTAB; where NHTAB =3D . > > - section 3.3: For the Record-Type directive, I think it would be more > > clear to change: "precede any CDNI Logging Record" -> > > "MUST precede all CDNI Logging Records" > > [IO] OK. The last phrase in Record-Type becomes "The first instance of > this > > directive MUST precede a Fields directive and MUST precede all CDNI > > Logging Records." > > - section 3.3: I think we should define a restriction on FIENAME to be > > not HTAB and not CRLF? Perhaps even just alphanumberic > > plus dash and underscore? This should be enforced by > > the IANA reviewer? > > [IO] I think excluding HTAB and CRLF would be ok in theory. I think > alphanumeric plus "-" and "_" is maybe just too rigid? > > > > - section 3.3: It was not clear to me initially, what this sentance is > > attempting to say. 3.4 has an example of a logging > > record and its list of fields, but it's not the only > > possible logging record, it's just the first one > > defined. When I first read this, I interpreted it as > > all possible logging records are defined in 3.4. > > " The names of the fields, as well as their > > possible occurrences, are specified for each type of CDNI > > Logging Records in Section 3.4." > > Perhaps it couldbe clarified to say something like: > > " The names of the fields, as well as their > > possible occurrences, MUST be specified in the referenced > > document of the CDNI Logging Record-types registry (Section > > 5.2), for each CDNI Logging Record-Type. This document > > defines the names of the fields, as well as their possible > > occurrences, for the "cdni_http_request_v1" Record-Type in > > Section 3.4.1." > > [IO] Done by Fran=E7ois. > > - section 3.3: Just to clarify, this statement asserts that the file > > is "non-corrupted", but makes no guarantee that it is > > tamper-proof or tamper-evident (a la MITM attack)? > > " If the > > two values are equal, then the received CDNI Logging File MUST > > be considered non-corrupted." > > [IO] That is correct. Remember the long discussions we had about non- > repudiation? In the end, I think the general idea was that authentication > and confidentiality for the logging files are handled by using HTTPS in > the ATOM protocol. > > - section 3.4.1: For any field value with a format defined as > > NHTABSTRING, don't we also need to exclude CRLF from > > the string? > > [IO] Done. > > - section 3.4.1: For protocol, do we want this to be extensible to > > HTTP/2.0? Does the normative reference to RFC2616 > > restrict this to HTTP/1.0 and HTTP/1.1? > > I had assumed that the v1 in "cdni_http_request_v1" > > referred to the Logging Record version, but perhaps > > it instead refers to the HTTP version? This is > > probably worth clarifying. > > [IO] Added the following to the description of Record-Type: "Note that th= e > cdni_http_request_v1 Record-Type directive refers strictly to the set of > Logging Records encompassed by the current version of this document. At > the time of publishing, it includes HTTP/1.0 and HTTP/1.1 requests as > specified in RFC 2616". > > - section 3.4.1: In the sc-total-bytes and sc-entity-bytes field value > > descriptions, the parenthetical references to HTTP > > headers seems to imply some inherent relationship > > between the headers and the status line, which I do > > not believe exists, per section 6 of RFC2616. > > " This includes the bytes of the Status-Line (including HTTP > > headers)" > > " This does not include the bytes of the Status-Line > > (and therefore does not include the bytes of the HTTP headers)". > > I think it would be clearer to say: > > " This includes the bytes of the Status-Line and the bytes > > of the HTTP headers" > > " This does not include the bytes of the Status-Line > > or the bytes of the HTTP headers". > > [IO] Done. > > - section 3.4.1: For all the fields values whos format is QSTRING, the > > field value description should be updated to indicate > > that the value is not actually "as received" or "as > > it appears in the response", etc., but rather that > > value encased in double quotes with any double quotes > > in that value escaped by an additional double quote? > > - section 3.4.1: I found the following text odd, in that the normative > > statement is that the value must be either something or > > nothing, which is somewhat tautological. Should this > > just be a MAY since its optional? > > " there MUST be zero, one or any number of instance" > > - section 3.4.1: For the s-sid field, is the only allowable use of > > this field for HAS delivery? Or can the field be > > used to group requests for any content? If it is > > really the latter, this should be clarified. > > " this contains the value of a Session IDentifier > > generated by the dCDN for a specific HTTP Adaptive Streaming > > (HAS) session" > > - section 3.4.1: Is it really the logging implementation that selects > > the fields? That does not sound correct to me? I > > would suggest removing: "by the implementation > > generating the CDNI Logging File" from this text: > > "The set > > of such fields name actually listed in the "Fields" directive is > > selected by the implementation generating the CDNI Logging File based > > on agreements between the interconnected CDNs established through" > > - section 3.4.1: I would suggestion removing "in that case, " from > > this sentance: > > "When such a field name is listed in the "Fields" > > directive, the corresponding field value MUST be included in the > > Logging Record; in that case, if the value for the field is not > > available, this MUST be conveyed via a dash character ("-")." > > - section 3.4.1: Just to clarify, the following text is defining the > > MTI fields for dCDNs. > > "A dCDN-side implementation of the CDNI Logging interface MUST support > > the ability to include valid values for the following Logging Fields" > > Would it be valid to always put a dash ("-")? Dash > > is a valid value, but does not require the dCDN to > > actually support parsing/producing any given field. > > - section 3.5: The UUID directive is not QSTRING, its NHTABSTRING, so > > can I assume that the double quotes are actually part > > of the UUID? Or is this example incorrect? > > " #UUID:"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"" > > - section 4.1: The terms "server-side" and "client-side" essentially > > refer to the "dCDN" and "uCDN", respectively, correct? > > I think it would be easier to follow if we used "dCDN" > > and "uCDN" since client and server are used for other > > purposes with other meanings in other parts of the draft. > > - section 4.1.1: What is an "IRI"? Should that be "URI" or "URN"? > > - section 4.1.2: Just to clarify, the "archive document" refers to > > past contents of the atom feed, correct? This > > section makes no statement about how long old logging > > files should be kept for, only how long old atom feed > > documents are held for? Should we? > > - section 4.2: Do we have thoughts on future HTTP/2.0 support? Not > > that I necessarily think that things like multiplexing > > would necessarily be beneficial to log retrieval, but > > should we consider the possibility of HTTP/2.0 > > obsoleting HTTP/1.1 in a few years? Would we have to > > rev the LI RFC at that point? > > " MUST use HTTP v1.1 ( [RFC2616]);" > > - section 5.1: Should we add instructions to the implied expert > > reviewer requiring that each specification defining a > > new directive contain the same type of information for > > each directive as in 3.3 (i.e., format, directive > > value, and occurrence)? > > - section 5.2: Should we add instructions to the implied expert > > reviewer requiring that each specification defining a > > new record-type contain the same type of information > > for each field as in 3.4.1 (i.e., field name, format, > > field value, and occurrence)? > > - section 5.3: Should the Field Names registry really be a subregistry > > under the Record-types registry? Without the scope of > > the Record-Type, these field names cannot be used for > > any other Record-Type, e.g., "date" and "time" can only > > ever be used by cdni_http_request_v1? Or at a minimum, > > they must have the exact same meaning? If that is the > > intent, then we may want to make that explicit in the > > text. > > - section 6.1: I believe this is implying that mutual authentication > > SHOULD be used? Should that be made explicit? > > " the dCDN and uCDN to authenticate each other (to ensure they are > > transmitting/receiving CDNI Logging File from an authenticated > > CDN) > > - section 6.1: Do we want to make an explicit statement about privacy > > of End-User information? And possibly an explicit > > statement about the acceptability of alternate methods > > for ensuring confidentiality of End-User information > > (e.g., an IPSec tunnel between CDNs, or physically > > secured internal network between two CDNs owned by the > > same corporate entity)? > > " the CDNI Logging information to be transmitted with > > confidentiality" > > Note: The privacy section (6.3) talks about > > anonymization between dCDN and uCDN, however, > > this is more about leaking even anonymized data. > > > > > > > > - appendix A: Is this going to be removed? > > [IO] From what I hear, yes. Do you want to keep it? :) > > nits: > > - section 1.1: "real time" -> "real-time" > > - section 2.1: ", uCDN uses" -> ", the uCDN uses" > > - section 2.1: "delivery operated by" -> "delivery performed by" > > - section 2.1: "non real-time" -> "non-real-time" > > - section 2.1: "to CSP." -> "to the CSP." > > - section 2.1: ", uCDN merges" -> ", the uCDN merges" > > - section 2.1: ". uCDN may also" -> ". the uCDN may also" > > - section 2.1: "on his behalf." -> "on the CSP's behalf." > > - section 2.1: "e.g., dCDN-3" -> "i.e., dCDN-3" > > - section 2.1: "format that are" -> "formats that are" > > - section 2.2: "more or less" -> "more or fewer" > > - section 2.2: "i.e., there may be" -> "e.g., there may be" > > - section 2.2.3: "may require to" -> "may be required to" > > - section 2.2.3: "by every Surrogate" -> "by each Surrogate" > > - section 2.2.3: "hostnames is not" -> "hostnames are not" > > - section 2.2.4: "real time" -> "real-time" > > - section 2.2.5.6.2: "uCDN and dCDN may" -> "the uCDN and dCDN may" > > - section 2.2.5.6.2: "Top 10 of the most" -> "Top 10 most" > > - section 3.2: "CDNI logging field" -> "CDNI Logging Field" > > - section 3.2: "close to intra-CDN logging format" -> > > "close to the intra-CDN Log format" > > - section 3.3: "File ." -> "File." > > - section 3.3: "to HTTP request" -> "to HTTP requests" > > - section 3.3: "each type of CDNI Logging Records" -> > > "each type of CDNI Logging Record" > > - section 3.4.1: "prededing" -> "preceding" > > - section 3.4.1: "any number of instance" -> "any number of instances" > > - section 3.4.1: "dCDN i.e." -> "dCDN, i.e., " > > - section 3.4.1: "MUST list all the fields name whose" -> > > "MUST contain all the field names whose" > > - section 3.4.1: "The fields name" -> "The field names" > > - section 3.4.1: "cs- method" -> "cs-method" > > - section 3.4.1: "sc- total-bytes" -> "sc-total-bytes" > > - section 4: "each of these CDNI Logging File" -> > > "each of these CDNI Logging Files" > > - section 4: "at the uCDN convenience" -> "at the uCDN's convenience" > > - section 4: "as per the present document generating CDNI Logging file" -= > > > ", as per the present document, generating CDNI Logging files" > > - section 4: "as per the present document consuming CDNI Logging file" -> > > ", as per the present document, consuming CDNI Logging files" > > - section 4: "document ." -> "document." > > - section 4.1.2: "MAY be unable to serve" -> > > "MAY indicate its inability to serve" > > - section 4.1.3: "redundancy, CDNI Logging" -> "redundancy. CDNI Logging" > > - section 4.2: "( [RFC2616])" -> "[RFC2616]" > > - section 4.2: "MAY be unable to serve" -> > > "MAY indicate its inability to serve" > > - section 6.3: "such as how much bytes of the content has been watched" -= > > > "such as how many bytes of the content have been watched" > > [IO] Nits are done. > > > > > _________________________________________________________________________= _ > _______________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Fri Nov 29 06:44:38 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37A21AD8ED for ; Fri, 29 Nov 2013 06:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EB6zHprr4DB for ; Fri, 29 Nov 2013 06:44:37 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 88CBA1A1F54 for ; Fri, 29 Nov 2013 06:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=381; q=dns/txt; s=iport; t=1385736276; x=1386945876; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=MgKCHONwZfFj5nqUMD5MXEK0VLnbom+m6Q55o0XdwXg=; b=NmShFaby5iMSpqDdzZjkY52Uh0bPwT7U4WsOJdtNhWc5OPHYOGB66F5v ob40nzutydXAVkjHni9rNMXCf5VNP8aXCgPEToyuQXSOc7xXdVoO3WWXr qK8CdJ0E2FKaRU39bcwaz8mOLO4ZqR0Pf5BC0AW0sgdtZ3NqZBO/Cg7NA E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQFAKqnmFKtJV2a/2dsb2JhbABZgwc4U7hagSEWbQeCLDo/EgE+QicEDg6HeA3ALhePCIMngRMDmBSSE4Mpgio X-IronPort-AV: E=Sophos;i="4.93,798,1378857600"; d="scan'208";a="3144413" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 29 Nov 2013 14:44:36 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rATEiZVR008250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 29 Nov 2013 14:44:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Fri, 29 Nov 2013 08:44:35 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: draft CDNI WG Meeting Minutes posted Thread-Index: AQHO7RGFS4ciCH+4SE2SmvJBfFToSg== Date: Fri, 29 Nov 2013 14:44:34 +0000 Message-ID: <05ED2FAA-84C9-4256-BA1C-9431CE20C3A9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] draft CDNI WG Meeting Minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 14:44:39 -0000 Folks, Draft minutes have been uploaded: http://www.ietf.org/proceedings/88/minutes/minutes-88-cdni Please comment/correct as needed. Cheers Francois PS1: Thanks to Matt and Jan for taking notes during the meeting. PS2: I could not make use of the audio recording (it comes out extremely fa= int during our session) - if you guys succeeded, please let me know.= From iuniana.oprescu@orange.com Fri Nov 29 07:13:27 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3116C1ADBCB for ; Fri, 29 Nov 2013 07:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waEyMsKvCeBF for ; Fri, 29 Nov 2013 07:13:26 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id D3BD61AD94A for ; Fri, 29 Nov 2013 07:13:25 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 729293B4273; Fri, 29 Nov 2013 16:13:24 +0100 (CET) Received: from pmexch31.intranet-paris.francetelecom.fr (unknown [10.100.76.21]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 54F30180090; Fri, 29 Nov 2013 16:13:24 +0100 (CET) Received: from PMEXCB1D.intranet-paris.francetelecom.fr ([10.100.76.11]) by pmexch31.intranet-paris.francetelecom.fr ([10.100.76.21]) with mapi; Fri, 29 Nov 2013 16:13:24 +0100 From: To: "Francois Le Faucheur (flefauch)" , "cdni@ietf.org" Date: Fri, 29 Nov 2013 16:13:22 +0100 Thread-Topic: draft CDNI WG Meeting Minutes posted Thread-Index: AQHO7RGFS4ciCH+4SE2SmvJBfFToSpo8ULpA Message-ID: <3509_1385738004_5298AF14_3509_6522_1_8F0D2F5E4AAB7249BC7339A3E944DEDD226FA2D644@PMEXCB1D.intranet-paris.francetelecom.fr> References: <05ED2FAA-84C9-4256-BA1C-9431CE20C3A9@cisco.com> In-Reply-To: <05ED2FAA-84C9-4256-BA1C-9431CE20C3A9@cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.29.44815 Subject: Re: [CDNi] draft CDNI WG Meeting Minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 15:13:27 -0000 Slight error about the note takers. I didn't take notes this time, I was too busy being cold...=20 -- iuniana -----Message d'origine----- De : CDNi [mailto:cdni-bounces@ietf.org] De la part de Francois Le Faucheur= (flefauch) Envoy=E9 : vendredi 29 novembre 2013 15:45 =C0 : cdni@ietf.org Objet : [CDNi] draft CDNI WG Meeting Minutes posted Folks, Draft minutes have been uploaded: http://www.ietf.org/proceedings/88/minutes/minutes-88-cdni Please comment/correct as needed. Cheers Francois PS1: Thanks to Matt and Jan for taking notes during the meeting. PS2: I could not make use of the audio recording (it comes out extremely fa= int during our session) - if you guys succeeded, please let me know. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From kevin.ma@azukisystems.com Fri Nov 29 07:33:31 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE431ADFC6 for ; Fri, 29 Nov 2013 07:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-CB_lvJqkek for ; Fri, 29 Nov 2013 07:33:29 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id C16D81ADFC0 for ; Fri, 29 Nov 2013 07:33:29 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5DB50555E39; Fri, 29 Nov 2013 10:33:28 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B8064555CE8; Fri, 29 Nov 2013 10:33:27 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Fri, 29 Nov 2013 10:33:27 -0500 From: Kevin J Ma To: "Francois Le Faucheur (flefauch)" , "cdni@ietf.org" Date: Fri, 29 Nov 2013 10:33:26 -0500 Thread-Topic: draft CDNI WG Meeting Minutes posted Thread-Index: AQHO7RGFS4ciCH+4SE2SmvJBfFToSpo8VfPA Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FB29F@MAILR002.mail.lan> References: <05ED2FAA-84C9-4256-BA1C-9431CE20C3A9@cisco.com> In-Reply-To: <05ED2FAA-84C9-4256-BA1C-9431CE20C3A9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] draft CDNI WG Meeting Minutes posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 15:33:31 -0000 under rate pacing: - i think the "???" was Scott Leibrand? - typo: "doe snot" -> "does not"=20 > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le > Faucheur (flefauch) > Sent: Friday, November 29, 2013 9:45 AM > To: cdni@ietf.org > Subject: [CDNi] draft CDNI WG Meeting Minutes posted >=20 > Folks, >=20 > Draft minutes have been uploaded: > http://www.ietf.org/proceedings/88/minutes/minutes-88-cdni >=20 > Please comment/correct as needed. >=20 > Cheers >=20 > Francois >=20 > PS1: Thanks to Matt and Jan for taking notes during the meeting. > PS2: I could not make use of the audio recording (it comes out extremely > faint during our session) - if you guys succeeded, please let me know. > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni