From flefauch@cisco.com Tue May 24 06:46:49 2011 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 563D1E074C for ; Tue, 24 May 2011 06:46:49 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPdijTuSLpxo for ; Tue, 24 May 2011 06:46:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4630DE0747 for ; Tue, 24 May 2011 06:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=468; q=dns/txt; s=iport; t=1306244808; x=1307454408; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=w1gntgGeLkPtdX4tCDgxmhAmF4L0KZz8+jKNxbkRiHk=; b=Fc6NEm8o0KAjCVwftGZFkoSHyxJbMfwOmfxt+v8h6E2GIe8LhRS64XiN cXuy9yt29RhcuxrSFQirqTn8KLRs3MrXN42VxCtzU4sKHh21mZxfuta6K vnD5kEkUB8kuV7rxOLXU8IPHTyMoqerBkROkxqQciERmDigKonF5PBeRZ 0=; X-IronPort-AV: E=Sophos;i="4.65,261,1304294400"; d="scan'208";a="90434109" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 24 May 2011 13:46:47 +0000 Received: from [144.254.53.249] ([144.254.53.249]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4ODkjEe012431; Tue, 24 May 2011 13:46:47 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2011 15:48:34 +0200 Message-Id: To: Kevin J Ma Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: [CDNi] incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements 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, 24 May 2011 13:46:49 -0000 Hello Kevin, I believe we had agreed in Prague that a couple of requirements that = were implied in cdni-publisher-use-cases should make their way into = cdni-requirements. Could you recap on those so we can consider/discuss as we rev up = cdni-requirements? Thanks Francois PS: I believe the IESG has not yet made a final determination with = respect to creation of a CDNI WG. But I suggest we resume the = work/progress on this list nonetheless.= From kevin.ma@azukisystems.com Tue May 24 17:01:29 2011 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 AFBBCE0759 for ; Tue, 24 May 2011 17:01:29 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V9PNti6sTcg for ; Tue, 24 May 2011 17:01:29 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by ietfa.amsl.com (Postfix) with ESMTP id 191CAE06D7 for ; Tue, 24 May 2011 17:01:29 -0700 (PDT) Received: from st21.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 5CDF1553478; Tue, 24 May 2011 20:01:28 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id BCA7B5532FD; Tue, 24 May 2011 20:01:27 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 24 May 2011 20:00:24 -0400 From: Kevin J Ma To: Francois Le Faucheur Date: Tue, 24 May 2011 20:01:21 -0400 Thread-Topic: incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements Thread-Index: AcwaGOtq2zHTvjevRoCbAt4twxu19AALNG1A Message-ID: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@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] incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements 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, 25 May 2011 00:01:29 -0000 Francois, We had discussed updating three of the requirements: - R36 discusses limiting the number of redirects for a content request. We interpret this as a hop count? For certain types of live content (e.g., HLS) it might be advantageous to include a time-based limit. Can we modify the text to include an optional temporal limit? e.g.: "R36 The CDNI Request-Routing protocol SHOULD support an optional mechanism enforcing a limit on the number of successive CDN redirections or the total elapsed time for a given request." - R38 discusses pushing upstream metadata to the downstream CDN. It was not clear if this was inclusive of all hierarchical metadata, i.e., can/should the upstream send aggregate default metadata, which may be useful in future requests for related content? Can we modify the text to clarify the conveyance of inherited metadata? e.g.: "R38 The CDNI Request-Routing protocol MAY also allow the Upstream CDN to convey information pointing to CDNI metadata associated with the requested content or an object set to which the requested content belongs." - R58 lists potential content distribution control policies. There are sometimes contractual obligations which limit which CDNs may be used. Can we add a bullet for whitelisting/blacklisting CDNs? e.g.: "* delegation whitelist/blacklist (i.e. Information defining which Downstream CDNs the content may be delivered through)" thanx! -- Kevin J. Ma > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Tuesday, May 24, 2011 9:49 AM > To: Kevin J Ma > Cc: Le Faucheur Francois; cdni@ietf.org > Subject: incorporating a few requirements from cdni-publisher-use-cases > into cdni-requirements >=20 > Hello Kevin, >=20 > I believe we had agreed in Prague that a couple of requirements that were > implied in cdni-publisher-use-cases should make their way into cdni- > requirements. > Could you recap on those so we can consider/discuss as we rev up cdni- > requirements? >=20 > Thanks >=20 > Francois >=20 > PS: I believe the IESG has not yet made a final determination with respec= t > to creation of a CDNI WG. But I suggest we resume the work/progress on > this list nonetheless. From haibin.song@huawei.com Tue May 24 23:23:02 2011 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 25A89E06BF for ; Tue, 24 May 2011 23:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTYi1Oj0KJW1 for ; Tue, 24 May 2011 23:23:01 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6A485E065B for ; Tue, 24 May 2011 23:23:01 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ004MXN1TZ1@szxga03-in.huawei.com> for cdni@ietf.org; Wed, 25 May 2011 14:22:42 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLQ00JPTN1T71@szxga03-in.huawei.com> for cdni@ietf.org; Wed, 25 May 2011 14:22:41 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 25 May 2011 14:22:38 +0800 Received: from SZXEML505-MBX.china.huawei.com ([169.254.2.253]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Wed, 25 May 2011 14:22:39 +0800 Date: Wed, 25 May 2011 06:22:39 +0000 From: Songhaibin In-reply-to: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> X-Originating-IP: [10.138.41.119] To: Kevin J Ma , Francois Le Faucheur Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [CDNi] incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements Thread-index: AQHMGm7stHLrMJEa5Euo9tjq/fEx0ZSdEuMA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> Cc: "cdni@ietf.org" Subject: Re: [CDNi] incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements 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, 25 May 2011 06:23:02 -0000 > For certain types of live content > (e.g., HLS) it might be advantageous to include a time-based limit. It can be done if there is time synchronization. BR, -Haibin > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Kevin J Ma > Sent: Wednesday, May 25, 2011 8:01 AM > To: Francois Le Faucheur > Cc: cdni@ietf.org > Subject: Re: [CDNi] incorporating a few requirements from > cdni-publisher-use-cases into cdni-requirements > > Francois, > > We had discussed updating three of the requirements: > > - R36 discusses limiting the number of redirects for a content request. > We interpret this as a hop count? For certain types of live content > (e.g., HLS) it might be advantageous to include a time-based limit. > Can we modify the text to include an optional temporal limit? e.g.: > > "R36 The CDNI Request-Routing protocol SHOULD support an optional > mechanism enforcing a limit on the number of successive CDN > redirections or the total elapsed time for a given request." > > - R38 discusses pushing upstream metadata to the downstream CDN. It > was not clear if this was inclusive of all hierarchical metadata, > i.e., can/should the upstream send aggregate default metadata, which > may be useful in future requests for related content? Can we modify > the text to clarify the conveyance of inherited metadata? e.g.: > > "R38 The CDNI Request-Routing protocol MAY also allow the Upstream > CDN to convey information pointing to CDNI metadata associated > with the requested content or an object set to which the > requested content belongs." > > - R58 lists potential content distribution control policies. There are > sometimes contractual obligations which limit which CDNs may be used. > Can we add a bullet for whitelisting/blacklisting CDNs? e.g.: > > "* delegation whitelist/blacklist (i.e. Information defining > which Downstream CDNs the content may be delivered through)" > > thanx! > > -- Kevin J. Ma > > > -----Original Message----- > > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > > Sent: Tuesday, May 24, 2011 9:49 AM > > To: Kevin J Ma > > Cc: Le Faucheur Francois; cdni@ietf.org > > Subject: incorporating a few requirements from cdni-publisher-use-cases > > into cdni-requirements > > > > Hello Kevin, > > > > I believe we had agreed in Prague that a couple of requirements that were > > implied in cdni-publisher-use-cases should make their way into cdni- > > requirements. > > Could you recap on those so we can consider/discuss as we rev up cdni- > > requirements? > > > > Thanks > > > > Francois > > > > PS: I believe the IESG has not yet made a final determination with respect > > to creation of a CDNI WG. But I suggest we resume the work/progress on > > this list nonetheless. > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From eburger@standardstrack.com Wed May 25 10:20:59 2011 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 D6EBBE0755 for ; Wed, 25 May 2011 10:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSiC82D2z2rl for ; Wed, 25 May 2011 10:20:59 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [66.117.3.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3F31AE075A for ; Wed, 25 May 2011 10:20:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=E/QkU3uBZjBWx90P0JlThC2g4mImLGi1cAewpof0LDteejVnlauF9KjkPmy4k1GUhuF+t4IyiGebUGvLJ8vJzgbSACDEjYT1TiGYuxl2IgblG8nfy4+mysQ9Fmju/WGa; Received: from [69.241.19.12] (helo=[10.36.97.44]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QPHkV-0004DF-SC; Wed, 25 May 2011 10:20:00 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-207--528143906; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> Date: Wed, 25 May 2011 13:20:54 -0400 Message-Id: <89197B0A-FBB5-4EDC-B6FB-D7BE43BE27D7@standardstrack.com> References: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com Cc: cdni@ietf.org Subject: Re: [CDNi] incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements 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, 25 May 2011 17:20:59 -0000 --Apple-Mail-207--528143906 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Any time you have a SHOULD, you really need to enumerate when it is not = appropriate to do the behaviour. Otherwise you are really promulgating = a MAY. In this case, I cannot think of the situation where not to do it, = particularly since the mechanism is optional. Therefore, I would = suggest either: "R36 The CDNI Request-Routing protocol MUST support an optional mechanism enforcing a limit on the number of successive CDN redirections or the total elapsed time for a given request." or "R36 The CDNI Request-Routing protocol MAY support a mechanism enforcing a limit on the number of successive CDN redirections or the total elapsed time for a given request." On May 24, 2011, at 8:01 PM, Kevin J Ma wrote: > - R36 discusses limiting the number of redirects for a content = request. > We interpret this as a hop count? For certain types of live = content > (e.g., HLS) it might be advantageous to include a time-based limit. > Can we modify the text to include an optional temporal limit? = e.g.: >=20 > "R36 The CDNI Request-Routing protocol SHOULD support an optional > mechanism enforcing a limit on the number of successive CDN > redirections or the total elapsed time for a given request." --Apple-Mail-207--528143906 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA1MjUxNzIwNTRaMCMGCSqGSIb3DQEJ BDEWBBRf7svRHFhFtOz9M7mIJd3Dsfy7MDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAC7oJSmAa5kzQG+JKwFiJTy25MaDAHnKk+p7zwWciDT6YQ8a 0/Joa9GybUVdoa2HUvW+qI5+vyQ0/ZZuqdPZNfAIBQAwrkLnFofKqUf7b4k4iBxKgZIwLlms8fHa yDseDlfeshB6+QlgW5zSbgohRSSYTFoAjVI28rSy8GEoPdSfT4l/iJN2nP/QHxK7TN/yfyoxiFN2 eKdFFNAJhsT5v7o/fkZns/8duwqEXthvDDFJIUw/tAmL7KC5F6ss0BQ2Aydu1ycmxLlqLhFjTuEL wlAWVjg9M+0sJ4PBCJDC5EbND+q7fCytgcNylZZgGFztBoXoG3wlrqD68CzkGeQaJwwAAAAAAAA= --Apple-Mail-207--528143906-- From vumip1@gmail.com Thu May 26 07:44:31 2011 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 56627E0744 for ; Thu, 26 May 2011 07:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SSlkqb4x9K5 for ; Thu, 26 May 2011 07:44:30 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id F344AE06FE for ; Thu, 26 May 2011 07:44:29 -0700 (PDT) Received: by gwb20 with SMTP id 20so439264gwb.31 for ; Thu, 26 May 2011 07:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=N+DArOyefj76tlKvqO6Sv6RvkYcqjyYpa8Xv3Ry3LFE=; b=nrFv7QLre1f17lCVtSxFhIwFFRvJGfnxKoYXL/1OApRWWZCLPBNoJSuhMlU+Xsnh0Z Iik7m+AuggRzbd+jcPKnSiQ2hMn5u57YaCKfmOKlu/J26x/4YTGG5SvmJPT5kOQknoNe o0uY4hJXTfmxaNoN+KaJV3XtiQyo2k8x4biPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fCm6lZ6zmK7CIdJh3CLtUSKsbyzNhiujr+/noQtyFrA2p78BwETMx6y1owpbG2c2Y5 glXSJlCu26z3IGxxjy6bynagxApD0ALCe51tkrLmnXVUFnWKcIrkeHvcF1HnHc+3jFIh JPXU3LJ6jsi2/Mwc101AeRzscpAcXI7kZIzd8= MIME-Version: 1.0 Received: by 10.236.176.69 with SMTP id a45mr1208938yhm.71.1306420581177; Thu, 26 May 2011 07:36:21 -0700 (PDT) Received: by 10.236.136.70 with HTTP; Thu, 26 May 2011 07:36:21 -0700 (PDT) In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> Date: Thu, 26 May 2011 10:36:21 -0400 Message-ID: From: Bhumip Khasnabish To: Kevin J Ma Content-Type: multipart/alternative; boundary=20cf303b39d3ab1a4704a42ebec4 Cc: "cdni@ietf.org" Subject: Re: [CDNi] incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements 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, 26 May 2011 14:44:31 -0000 --20cf303b39d3ab1a4704a42ebec4 Content-Type: text/plain; charset=ISO-8859-1 "R38 The CDNI Request-Routing protocol MAY also allow the Upstream CDN to convey information pointing to CDNI metadata associated with the requested content or an object set to which the requested content belongs." Question/concern: It may not be feasible to share all of the available " CDNI metadata associated with the requested content " al the time .. may need a qualifier as to when to share and how much to share with whom (may be a decision based on congestion, policy, traffic-type, basic/prime peering, etc. etc.) Thanks. Bhumip On Tue, May 24, 2011 at 8:01 PM, Kevin J Ma wrote: > Francois, > > We had discussed updating three of the requirements: > > - R36 discusses limiting the number of redirects for a content request. > We interpret this as a hop count? For certain types of live content > (e.g., HLS) it might be advantageous to include a time-based limit. > Can we modify the text to include an optional temporal limit? e.g.: > > "R36 The CDNI Request-Routing protocol SHOULD support an optional > mechanism enforcing a limit on the number of successive CDN > redirections or the total elapsed time for a given request." > > - R38 discusses pushing upstream metadata to the downstream CDN. It > was not clear if this was inclusive of all hierarchical metadata, > i.e., can/should the upstream send aggregate default metadata, which > may be useful in future requests for related content? Can we modify > the text to clarify the conveyance of inherited metadata? e.g.: > > "R38 The CDNI Request-Routing protocol MAY also allow the Upstream > CDN to convey information pointing to CDNI metadata associated > with the requested content or an object set to which the > requested content belongs." > > - R58 lists potential content distribution control policies. There are > sometimes contractual obligations which limit which CDNs may be used. > Can we add a bullet for whitelisting/blacklisting CDNs? e.g.: > > "* delegation whitelist/blacklist (i.e. Information defining > which Downstream CDNs the content may be delivered through)" > > thanx! > > -- Kevin J. Ma > > > -----Original Message----- > > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > > Sent: Tuesday, May 24, 2011 9:49 AM > > To: Kevin J Ma > > Cc: Le Faucheur Francois; cdni@ietf.org > > Subject: incorporating a few requirements from cdni-publisher-use-cases > > into cdni-requirements > > > > Hello Kevin, > > > > I believe we had agreed in Prague that a couple of requirements that were > > implied in cdni-publisher-use-cases should make their way into cdni- > > requirements. > > Could you recap on those so we can consider/discuss as we rev up cdni- > > requirements? > > > > Thanks > > > > Francois > > > > PS: I believe the IESG has not yet made a final determination with > respect > > to creation of a CDNI WG. But I suggest we resume the work/progress on > > this list nonetheless. > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --20cf303b39d3ab1a4704a42ebec4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0=A0=A0"R38 =A0The CDNI Request-Routing protocol MAY also allow= the Upstream
=A0 =A0 =A0 =A0 =A0CDN to convey information pointing to C= DNI metadata associated
=A0 =A0 =A0 =A0 =A0with the requested content or= an object set to which the
=A0 =A0 =A0 =A0 =A0requested content belongs."
=A0
Question/concern: It may not be feasible to sh= are all of the available " CDNI metadata associated with the requested= content " al the time .. may need a qualifier as to when to share and= how much to share with whom (may be a decision based on congestion, policy= , traffic-type, basic/prime peering, etc. etc.)
Thanks.
=A0
Bhumip
=A0

=A0
On Tue, May 24, 2011 at 8:01 PM, Kevin J Ma <kevin.ma@azukisystems.com<= /a>> wrote:
Francois,

=A0We had discu= ssed updating three of the requirements:

=A0- R36 discusses limiting= the number of redirects for a content request.
=A0 =A0We interpret this as a hop count? =A0For certain types of live conte= nt
=A0 =A0(e.g., HLS) it might be advantageous to include a time-based l= imit.
=A0 =A0Can we modify the text to include an optional temporal limi= t? =A0e.g.:

=A0 =A0"R36 =A0The CDNI Request-Routing protocol SHOULD support an= optional
=A0 =A0 =A0 =A0 =A0mechanism enforcing a limit on the number o= f successive CDN
=A0 =A0 =A0 =A0 =A0redirections or the total elapsed ti= me for a given request."

=A0- R38 discusses pushing upstream metadata to the downstream CDN. =A0= It
=A0 =A0was not clear if this was inclusive of all hierarchical metada= ta,
=A0 =A0i.e., can/should the upstream send aggregate default metadata= , which
=A0 =A0may be useful in future requests for related content? =A0Can we modi= fy
=A0 =A0the text to clarify the conveyance of inherited metadata? =A0e= .g.:

=A0 =A0"R38 =A0The CDNI Request-Routing protocol MAY also = allow the Upstream
=A0 =A0 =A0 =A0 =A0CDN to convey information pointing to CDNI metadata asso= ciated
=A0 =A0 =A0 =A0 =A0with the requested content or an object set to= which the
=A0 =A0 =A0 =A0 =A0requested content belongs."

= =A0- R58 lists potential content distribution control policies. =A0There ar= e
=A0 =A0sometimes contractual obligations which limit which CDNs may be used= .
=A0 =A0Can we add a bullet for whitelisting/blacklisting CDNs? =A0e.g.= :

=A0 =A0 =A0"* =A0 delegation whitelist/blacklist (i.e. =A0Inf= ormation defining
=A0 =A0 =A0 =A0 =A0 which Downstream CDNs the content may be delivered thro= ugh)"

thanx!

-- =A0Kevin J. Ma

> -----Original= Message-----
> From: Francois Le Faucheur [mailto:flefauch@cisco.com]
> Sent: Tuesday, May 24, 2011 9:49 AM
> To: Kevin J Ma
> Cc:= Le Faucheur Francois; c= dni@ietf.org
> Subject: incorporating a few requirements from cdn= i-publisher-use-cases
> into cdni-requirements
>
> Hello Kevin,
>
> I believe we had agreed in P= rague that a couple of requirements that were
> implied in cdni-publi= sher-use-cases should make their way into cdni-
> requirements.
> Could you recap on those so we can consider/discuss as we rev up cdni-=
> requirements?
>
> Thanks
>
> Francois
&= gt;
> PS: I believe the IESG has not yet made a final determination w= ith respect
> to creation of a CDNI WG. But I suggest we resume the work/progress on=
> this list nonetheless.
________________________________________= _______
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni


=A0=20 --20cf303b39d3ab1a4704a42ebec4-- From flefauch@cisco.com Thu May 26 08:36:27 2011 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 1B57CE070A for ; Thu, 26 May 2011 08:36:27 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnEbPCugDjRs for ; Thu, 26 May 2011 08:36:26 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id CCAF9E06D6 for ; Thu, 26 May 2011 08:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=3341; q=dns/txt; s=iport; t=1306424186; x=1307633786; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ZqQSitXhU+S8i0UkjOr+sAeXXR6p6gFIW1HENT38BYI=; b=Ci9Cj93lfNX+EABONkRfkXinLEuNbguu7uJFlNsBbeqVjPPEid9J1+A4 TiA5otFv4qYJGtl8MLbS3X7XwaZVCHVkg3ujCoUw5HoHKfTjyRlfHfgmS uHwL8J67RvHPetA7JtzfvCJ3YuyGvmrFrQnk3w7B8aWVBNhgK1V2f2mBA 4=; X-IronPort-AV: E=Sophos;i="4.65,273,1304294400"; d="scan'208";a="32458925" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 26 May 2011 15:36:18 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4QFaHmj030715; Thu, 26 May 2011 15:36:18 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> Date: Thu, 26 May 2011 17:38:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" Subject: [CDNi] Delay TTL in CDNI Request Routing (was Re: incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements) 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, 26 May 2011 15:36:27 -0000 Hi Kevin, Breaking this discussion into several threads to facilitate resolution: On 25 May 2011, at 02:01, Kevin J Ma wrote: > Francois, >=20 > We had discussed updating three of the requirements: >=20 > - R36 discusses limiting the number of redirects for a content = request. > We interpret this as a hop count? Right. ie effectively limit the number of CDNs that are involved in = cascaded redirections. Expected to be simple, yet achieves good things (redirection loop = prevention, rough bounding of overall redirection time, limit number of = players that will share the cost/revenue of delivery,..).=20 Note that this hop count limit applies to the scenario of "recursive = redirection" (not "iterative redirection"). > For certain types of live content > (e.g., HLS) it might be advantageous to include a time-based limit. > Can we modify the text to include an optional temporal limit? = e.g.: So, the trade-off here is less obvious to me. It may not be too hard to = include < timestamp + TTL> knobs in the CDNI request routing request, = but: * to enforce it, you'd need all CDNs in the path to use fairly = accurately synchronized timing (as Haibin pointed out) * the CDN-hop limit effectively already provides a very rough = form of control on redirection time (albeit less accurate) * a delay TTL could always be autonomously enforced by the = most-upstream CDN (i.e. when it gets the final CDNI Request Routing = response that has travelled through all CDNs) without any specific = mechanisms inside the CDNI request routing API itself.=20 * one potential value of adding a knob inside the CDNI request = routing API is that a downstream CDN could try become smart in order to = minimize occurrences of requests being dropped dead (ie exceeding the = TTL). To that end the CDN request routing systems on the redirection = path would have to try be smart and make judgment calls along the lines = of "oh, I see that this request has already lived quite a long life and = is getting close to its TTL, so should I try redirect at the risk of = exceeding the TTL and having it dropped dead, or should I overwrite my = normal redirection policy and not reroute further and serve myself?" . = This may not be a trivial decision, since request routing times of the = downstream CDN may greatly vary and be hard to predict. So this will end = up having a positive value in some case, and a negative value in other = cases. Are you more after: (i) a mechanism that simply discards a response that would be = too old (but could be implemented autonomously by the upmost CDN) or=20 (ii) a mechanisms that allows the CDNI system to avoid taking = too long to redirect (and "violates" its normal redirection policy when = needed)? If the latter, are you more after: (i) avoiding the transient situations (eg one of the request = routing system got temporarily overloaded and is atypically slow) or=20 (ii) avoiding inappropriate CDN routing policies that result in = very large redirection times (eg CDN1 in Europe redirects to a CDN in = Asia, that redirects to a CDN in America, that redirects to a CDN in = Europe,..) ? Is this something you see as really needed in Initial Scope? or in a = subsequent phase? Thanks Francois= From flefauch@cisco.com Thu May 26 09:05:07 2011 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 1BBB6E073C for ; Thu, 26 May 2011 09:05:07 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0t8RMRnrAV5 for ; Thu, 26 May 2011 09:05:06 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7F0E0734 for ; Thu, 26 May 2011 09:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=8941; q=dns/txt; s=iport; t=1306425905; x=1307635505; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=P96pZaux3b21xcoHZcGtOvyr5D9gijJi8ZB3P1GBwUE=; b=ObDU2J04VMMKuzn6FqngN3RtrxLt4p1jgjgQJm3Tp+qYGhEpqKEqTzeV cAb82IESn2TIL0yUCrM9LSR96UGiuMbr+2V3DWHbAcFaiWX3tqPcjR4zG E3ZI+To6MXfEAxK6eB3bZLyPzsuhPg/QB9fu5aphmowiiV1u6KT/D+opE E=; X-IronPort-AV: E=Sophos;i="4.65,273,1304294400"; d="scan'208,217";a="90910929" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 26 May 2011 16:05:04 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4QG53gI006469; Thu, 26 May 2011 16:05:03 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-259--446186674 From: Francois Le Faucheur In-Reply-To: <89197B0A-FBB5-4EDC-B6FB-D7BE43BE27D7@standardstrack.com> Date: Thu, 26 May 2011 18:06:51 +0200 Message-Id: References: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> <89197B0A-FBB5-4EDC-B6FB-D7BE43BE27D7@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements 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, 26 May 2011 16:05:07 -0000 --Apple-Mail-259--446186674 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Eric, On 25 May 2011, at 19:20, Eric Burger wrote: > Any time you have a SHOULD, you really need to enumerate when it is = not appropriate to do the behaviour. We plan to follow that convention for the actual protocol specs.=20 ie those that define what an implementation MUST/SHOULD/MAY do. But we followed a slightly different convention for the "Requirements" = document because it does not define the behavior required of an = implementation, I'd say it probably defines the behavior required of the = WG.=20 Considering requirements that are "Within Initial CDNI Scope":=20 The MUST is intended to mean something like: "the WG will specify a CDNI = protocol that does X. It is already clear that this is compatible with = the overall WG priorities, or it is clear that shipping a solution = without this does not make sense and would justify re-adjusting the WG = priorities, or both."=20 The SHOULD is intended to mean something like: "the WG will define a = CDNI protocol that does X unless the WG realizes that this would = compromise the overall WG priorities (for example it would involve = complexities that would result in delaying the milestones)." The MAY is intended to mean something like: "the WG will define a CDNI = protocol that does X if it has done the more important items and this = would not compromise the overall WG priorities." This question has come up before on the list and I had the impression = the group was fairly comfortable with that sort of convention . If it is acceptable to all, we could include these terminology = definitions into the Requirements document. Another option, would be to revisit all the SHOULDs/MAYs and, for each = of them, try make the final call as to whether we actually want to = support them or not (but that will involve detailed discussions into the = protocol themselves and making judgment calls on = complexities_vs_timing). So my preference is to stick to our current convention (ie define how = hard the WG needs to try address each requirement) and then have the = final calls actually made during the protocol definition phase. Makes sense? Francois > Otherwise you are really promulgating a MAY. >=20 > In this case, I cannot think of the situation where not to do it, = particularly since the mechanism is optional. Therefore, I would = suggest either: > "R36 The CDNI Request-Routing protocol MUST support an optional > mechanism enforcing a limit on the number of successive CDN > redirections or the total elapsed time for a given request." >=20 > or > "R36 The CDNI Request-Routing protocol MAY support a > mechanism enforcing a limit on the number of successive CDN > redirections or the total elapsed time for a given request." >=20 >=20 > On May 24, 2011, at 8:01 PM, Kevin J Ma wrote: >=20 >> - R36 discusses limiting the number of redirects for a content = request. >> We interpret this as a hop count? For certain types of live = content >> (e.g., HLS) it might be advantageous to include a time-based limit. >> Can we modify the text to include an optional temporal limit? = e.g.: >>=20 >> "R36 The CDNI Request-Routing protocol SHOULD support an optional >> mechanism enforcing a limit on the number of successive CDN >> redirections or the total elapsed time for a given request." >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail-259--446186674 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Eric,

On 25 May 2011, at 19:20, Eric Burger = wrote:

Any time you have a SHOULD, you really need to = enumerate when it is not appropriate to do the behaviour. =

We plan to follow that convention = for the actual protocol specs. 
ie those that define what = an implementation MUST/SHOULD/MAY do.

But we = followed a slightly different convention for the "Requirements" document = because it does not define the behavior required of an implementation, = I'd say it probably defines the behavior required of the = WG. 
Considering requirements that are "Within Initial = CDNI Scope": 
The MUST is intended to mean something = like: "the WG will specify a CDNI protocol that does X. It is already = clear that this is compatible with the overall WG priorities, or it is = clear that shipping a solution without this does not make sense and = would justify re-adjusting the WG priorities, or = both." 
The SHOULD is intended to mean something like: = "the WG will define a CDNI protocol that does X unless the WG realizes = that this would compromise the overall WG priorities (for example it = would involve complexities that would result in delaying the = milestones)."
The MAY is intended to mean something like: = "the WG will define a CDNI protocol that does X if it has done the more = important items and this would not compromise the overall WG = priorities."

This question has come up before = on the list and I had the impression the group was fairly comfortable = with that sort of convention .

If it is = acceptable to all, we could include these terminology definitions into = the Requirements document.
Another option, would be to revisit = all the SHOULDs/MAYs and, for each of them, try make the final = call as to whether we actually want to support them or not (but that = will involve detailed discussions into the protocol themselves and = making judgment calls on complexities_vs_timing).
So my = preference is to stick to our current convention (ie define how hard the = WG needs to try address each requirement) and then have the final calls = actually made during the protocol definition = phase.

Makes = sense?

Francois



 Otherwise you are really = promulgating a MAY.

In this case, I cannot think of the situation = where not to do it, particularly since the mechanism is optional. =  Therefore, I would suggest either:
  "R36  The = CDNI Request-Routing protocol MUST support an optional
=         mechanism enforcing a = limit on the number of successive CDN
=         redirections or the = total elapsed time for a given request."

or
  "R36 =  The CDNI Request-Routing protocol MAY support a
=         mechanism enforcing a = limit on the number of successive CDN
=         redirections or the = total elapsed time for a given request."


On May 24, 2011, at = 8:01 PM, Kevin J Ma wrote:

- R36 = discusses limiting the number of redirects for a content = request.
  We = interpret this as a hop count?  For certain types of live = content
  (e.g., = HLS) it might be advantageous to include a time-based = limit.
  Can we = modify the text to include an optional temporal limit? =  e.g.:

=   "R36  The CDNI Request-Routing protocol SHOULD support = an optional
=         mechanism enforcing a = limit on the number of successive CDN
=         redirections or the = total elapsed time for a given = request."

____________________________________________= ___
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni

Subject: Re: [CDNi] Delay TTL in CDNI Request Routing (was Re: incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements) 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, 26 May 2011 16:34:57 -0000 Hi Francois, The possible lack of time synchronization brings up a separate question about enforcement of signed URL expiration and more generally content expiration, though, the latter is admittedly on a much less granualar time scale, but we can leave that digression for the moment. To your later points, I was thinking about (ii) and (ii), i.e., not redirecting to a downstream CDN that would probably violate the R36 constraint. It could probably be done in other ways, but, if in a recursive redirection case, the upstream CDNs have latency estimates for the downstream CDNs, the aggregate estimates might be sufficient for providing a more accurate TTL than just hop count, without needing precise time synchronization. Granted thats probably a more detailed implementation consideration than we want to make at this time, it is just to say that time synchronization should not be the limiting factor. As for implementing it at the most-upstream CDN, that is certainly an option as well, but using an aggregate latency estimate might still require the accumulation of data during the request routing process. It may or may not affect the final protocol, but I guess the question is: is a time-based TTL a valid requirement? I don't think it would be unreasonable for the initial scope, but I don't necessarily think it is mandatory. thanx. -- Kevin J. Ma > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Thursday, May 26, 2011 11:38 AM > To: Kevin J Ma > Cc: Francois Le Faucheur; cdni@ietf.org > Subject: Delay TTL in CDNI Request Routing (was Re: incorporating a few > requirements from cdni-publisher-use-cases into cdni-requirements) >=20 > Hi Kevin, >=20 > Breaking this discussion into several threads to facilitate resolution: >=20 > On 25 May 2011, at 02:01, Kevin J Ma wrote: >=20 > > Francois, > > > > We had discussed updating three of the requirements: > > > > - R36 discusses limiting the number of redirects for a content request= . > > We interpret this as a hop count? >=20 > Right. ie effectively limit the number of CDNs that are involved in > cascaded redirections. > Expected to be simple, yet achieves good things (redirection loop > prevention, rough bounding of overall redirection time, limit number of > players that will share the cost/revenue of delivery,..). >=20 > Note that this hop count limit applies to the scenario of "recursive > redirection" (not "iterative redirection"). >=20 > > For certain types of live content > > (e.g., HLS) it might be advantageous to include a time-based limit. > > Can we modify the text to include an optional temporal limit? e.g.: >=20 > So, the trade-off here is less obvious to me. It may not be too hard to > include < timestamp + TTL> knobs in the CDNI request routing request, > but: > * to enforce it, you'd need all CDNs in the path to use fairly > accurately synchronized timing (as Haibin pointed out) > * the CDN-hop limit effectively already provides a very rough form > of control on redirection time (albeit less accurate) > * a delay TTL could always be autonomously enforced by the most- > upstream CDN (i.e. when it gets the final CDNI Request Routing response > that has travelled through all CDNs) without any specific mechanisms > inside the CDNI request routing API itself. > * one potential value of adding a knob inside the CDNI request > routing API is that a downstream CDN could try become smart in order to > minimize occurrences of requests being dropped dead (ie exceeding the > TTL). To that end the CDN request routing systems on the redirection path > would have to try be smart and make judgment calls along the lines of "oh= , > I see that this request has already lived quite a long life and is gettin= g > close to its TTL, so should I try redirect at the risk of exceeding the > TTL and having it dropped dead, or should I overwrite my normal > redirection policy and not reroute further and serve myself?" . This may > not be a trivial decision, since request routing times of the downstream > CDN may greatly vary and be hard to predict. So this will end up having a > positive value in some case, and a negative value in other cases. >=20 > Are you more after: > (i) a mechanism that simply discards a response that would be too > old (but could be implemented autonomously by the upmost CDN) or > (ii) a mechanisms that allows the CDNI system to avoid taking too > long to redirect (and "violates" its normal redirection policy when > needed)? >=20 > If the latter, are you more after: > (i) avoiding the transient situations (eg one of the request routing > system got temporarily overloaded and is atypically slow) or > (ii) avoiding inappropriate CDN routing policies that result in very > large redirection times (eg CDN1 in Europe redirects to a CDN in Asia, > that redirects to a CDN in America, that redirects to a CDN in Europe,..) > ? >=20 > Is this something you see as really needed in Initial Scope? or in a > subsequent phase? >=20 > Thanks >=20 > Francois From flefauch@cisco.com Thu May 26 09:51:06 2011 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 67AABE06D6 for ; Thu, 26 May 2011 09:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.888 X-Spam-Level: X-Spam-Status: No, score=-9.888 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL3cmEywxQ66 for ; Thu, 26 May 2011 09:51:05 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id CEF3FE0655 for ; Thu, 26 May 2011 09:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=32377; q=dns/txt; s=iport; t=1306428663; x=1307638263; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Gh1aRJdN0czvubBwZHrzpmnf5xZknUrulsw5/rNuhfg=; b=PcSkasuP3E9JZBPUPGoZ4/8UZAr86spjJz8TR+sDOk2AanhB82pQNihE IKUIwNNJcY/Tr0BvmsQrhrDar+r2oMNGbWvmPL5ACbHm2moF8kYOvfbKc hJ3xW5iiAamCxSvPwkcdLH6/q1Vjv+FdYuWGZcFwr2ys+Wl+9Wg9xX07G o=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.65,275,1304294400"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="32468703" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 26 May 2011 16:51:02 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4QGp1Ci017855; Thu, 26 May 2011 16:51:01 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-276--443430084 From: Francois Le Faucheur In-Reply-To: Date: Thu, 26 May 2011 18:52:47 +0200 Message-Id: References: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> <89197B0A-FBB5-4EDC-B6FB-D7BE43BE27D7@standardstrack.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org, Eric Burger Subject: Re: [CDNi] incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements 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, 26 May 2011 16:51:06 -0000 --Apple-Mail-276--443430084 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 26 May 2011, at 18:06, Francois Le Faucheur wrote: > Hi Eric, >=20 > On 25 May 2011, at 19:20, Eric Burger wrote: >=20 >> Any time you have a SHOULD, you really need to enumerate when it is = not appropriate to do the behaviour. >=20 > We plan to follow that convention for the actual protocol specs.=20 > ie those that define what an implementation MUST/SHOULD/MAY do. >=20 > But we followed a slightly different convention for the "Requirements" = document because it does not define the behavior required of an = implementation, I'd say it probably defines the behavior required of the = WG.=20 > Considering requirements that are "Within Initial CDNI Scope":=20 > The MUST is intended to mean something like: "the WG will specify a = CDNI protocol that does X. It is already clear that this is compatible = with the overall WG priorities, or it is clear that shipping a solution = without this does not make sense and would justify re-adjusting the WG = priorities, or both."=20 > The SHOULD is intended to mean something like: "the WG will define a = CDNI protocol that does X unless the WG realizes that this would = compromise the overall WG priorities (for example it would involve = complexities that would result in delaying the milestones)." > The MAY is intended to mean something like: "the WG will define a CDNI = protocol that does X if it has done the more important items and this = would not compromise the overall WG priorities." >=20 > This question has come up before on the list and I had the impression = the group was fairly comfortable with that sort of convention . >=20 > If it is acceptable to all, we could include these terminology = definitions into the Requirements document. and, perhaps, to avoid confusion with the RFC2119 terminology, we could = drop the ALL CAPS notation ie use must/should/may.=20 > Another option, would be to revisit all the SHOULDs/MAYs and, for each = of them, try make the final call as to whether we actually want to = support them or not (but that will involve detailed discussions into the = protocol themselves and making judgment calls on = complexities_vs_timing). > So my preference is to stick to our current convention (ie define how = hard the WG needs to try address each requirement) and then have the = final calls actually made during the protocol definition phase. >=20 > Makes sense? >=20 > Francois >=20 >=20 >=20 >> Otherwise you are really promulgating a MAY. >>=20 >> In this case, I cannot think of the situation where not to do it, = particularly since the mechanism is optional. Therefore, I would = suggest either: >> "R36 The CDNI Request-Routing protocol MUST support an optional >> mechanism enforcing a limit on the number of successive CDN >> redirections or the total elapsed time for a given request." >>=20 >> or >> "R36 The CDNI Request-Routing protocol MAY support a >> mechanism enforcing a limit on the number of successive CDN >> redirections or the total elapsed time for a given request." >>=20 >>=20 >> On May 24, 2011, at 8:01 PM, Kevin J Ma wrote: >>=20 >>> - R36 discusses limiting the number of redirects for a content = request. >>> We interpret this as a hop count? For certain types of live = content >>> (e.g., HLS) it might be advantageous to include a time-based = limit. >>> Can we modify the text to include an optional temporal limit? = e.g.: >>>=20 >>> "R36 The CDNI Request-Routing protocol SHOULD support an optional >>> mechanism enforcing a limit on the number of successive CDN >>> redirections or the total elapsed time for a given request." >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 >=20 Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-276--443430084 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-277--443430084 --Apple-Mail-277--443430084 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi = Eric,

On 25 May 2011, at 19:20, Eric Burger = wrote:

Any time you have a SHOULD, you really need to = enumerate when it is not appropriate to do the behaviour. =

We plan to follow that convention = for the actual protocol specs. 
ie those that define what = an implementation MUST/SHOULD/MAY do.

But we = followed a slightly different convention for the "Requirements" document = because it does not define the behavior required of an implementation, = I'd say it probably defines the behavior required of the = WG. 
Considering requirements that are "Within Initial = CDNI Scope": 
The MUST is intended to mean something = like: "the WG will specify a CDNI protocol that does X. It is already = clear that this is compatible with the overall WG priorities, or it is = clear that shipping a solution without this does not make sense and = would justify re-adjusting the WG priorities, or = both." 
The SHOULD is intended to mean something like: = "the WG will define a CDNI protocol that does X unless the WG realizes = that this would compromise the overall WG priorities (for example it = would involve complexities that would result in delaying the = milestones)."
The MAY is intended to mean something like: = "the WG will define a CDNI protocol that does X if it has done the more = important items and this would not compromise the overall WG = priorities."

This question has come up before = on the list and I had the impression the group was fairly comfortable = with that sort of convention .

If it is = acceptable to all, we could include these terminology definitions into = the Requirements = document.

and, = perhaps, to avoid confusion with the RFC2119  terminology, we could = drop the ALL CAPS notation ie use = must/should/may. 

Another option, = would be to revisit all the SHOULDs/MAYs and, for each of = them, try make the final call as to whether we actually want to = support them or not (but that will involve detailed discussions into the = protocol themselves and making judgment calls on = complexities_vs_timing).
So my preference is to stick to our = current convention (ie define how hard the WG needs to try address each = requirement) and then have the final calls actually made during the = protocol definition phase.

Makes = sense?

Francois



 Otherwise you are really = promulgating a MAY.

In this case, I cannot think of the situation = where not to do it, particularly since the mechanism is optional. =  Therefore, I would suggest either:
  "R36  The = CDNI Request-Routing protocol MUST support an optional
=         mechanism enforcing a = limit on the number of successive CDN
=         redirections or the = total elapsed time for a given request."

or
  "R36 =  The CDNI Request-Routing protocol MAY support a
=         mechanism enforcing a = limit on the number of successive CDN
=         redirections or the = total elapsed time for a given request."


On May 24, 2011, at = 8:01 PM, Kevin J Ma wrote:

- R36 = discusses limiting the number of redirects for a content = request.
  We = interpret this as a hop count?  For certain types of live = content
  (e.g., = HLS) it might be advantageous to include a time-based = limit.
  Can we = modify the text to include an optional temporal limit? =  e.g.:

=   "R36  The CDNI Request-Routing protocol SHOULD support = an optional
=         mechanism enforcing a = limit on the number of successive CDN
=         redirections or the = total elapsed time for a given = request."

____________________________________________= ___
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni



Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-277--443430084 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-277--443430084-- --Apple-Mail-276--443430084-- From flefauch@cisco.com Thu May 26 10:32:00 2011 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 4B0FBE0746 for ; Thu, 26 May 2011 10:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.421 X-Spam-Level: X-Spam-Status: No, score=-10.421 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylyVKoUAj1cR for ; Thu, 26 May 2011 10:31:54 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6E65DE0734 for ; Thu, 26 May 2011 10:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=18788; q=dns/txt; s=iport; t=1306431113; x=1307640713; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=DfieV2L78g/z1a1SG7VhrgM+XkMEEime8jvA95bbrls=; b=M0vzG0c7e8TfalhrBULKdATTLX/ysg0xhhGdYG5B7Z0UvGjlD2+tZB3W Xv1Obr51xcwcqxYeBN/y2c2nTXjnPjV1YlhhaaFsIk5QR7pHNDO9jz1rY v9wIZk31NqJ5qf1NKYDgz+qjuoEtK6w4UvnrIOZskEas0WYStbVD1g2VR 4=; X-IronPort-AV: E=Sophos;i="4.65,275,1304294400"; d="scan'208,217";a="32473433" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 26 May 2011 17:31:52 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4QHVpk9027663; Thu, 26 May 2011 17:31:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-294--440980966 From: Francois Le Faucheur In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6518BAC2C0C@MAILR002.mail.lan> Date: Thu, 26 May 2011 19:33:37 +0200 Message-Id: <1B3F9D9B-19A5-4BFB-AEC1-D39F42A745D7@cisco.com> References: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6518BAC2C0C@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" Subject: Re: [CDNi] Delay TTL in CDNI Request Routing (was Re: incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements) 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, 26 May 2011 17:32:00 -0000 --Apple-Mail-294--440980966 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 May 2011, at 18:34, Kevin J Ma wrote: > Hi Francois, >=20 > The possible lack of time synchronization brings up a separate = question > about enforcement of signed URL expiration and more generally content > expiration, though, the latter is admittedly on a much less granualar > time scale, Right. I don't see a practical issue here. Just like it is not an issue = with existing HTTP cache expiration mechanisms. > but we can leave that digression for the moment. >=20 > To your later points, I was thinking about (ii) and (ii), i.e., not > redirecting to a downstream CDN that would probably violate the R36 > constraint. I see. But I think having a knob in the CDNI Request Routing API would only = provide value if you want to support situations where: (i) redirecting some requests to a CDN would result in a = redirection time that exceeds the max redirection time for these = requests, AND (ii) redirecting some other requests to a CDN would NOT result = in a redirection time that exceeds the max redirection time for these = requests. Because if you are in a situation where all requests have the same max = redirection time, then you may as well update the whole redirection = policy (to no longer redirect to the dCDN) and be done with it.=20 > It could probably be done in other ways, but, if in a > recursive redirection case, the upstream CDNs have latency estimates > for the downstream CDNs, the aggregate estimates might be sufficient > for providing a more accurate TTL than just hop count, without = needing > precise time synchronization. Granted thats probably a more detailed > implementation consideration than we want to make at this time, it is > just to say that time synchronization should not be the limiting = factor. >=20 > As for implementing it at the most-upstream CDN, that is certainly an > option as well, but using an aggregate latency estimate might still > require the accumulation of data during the request routing process. > It may or may not affect the final protocol, but I guess the question > is: is a time-based TTL a valid requirement? >=20 > I don't think it would be unreasonable for the initial scope, but I > don't necessarily think it is mandatory. So my proposal is to add a standalone requirement for the delay-based = TTL (that is separate from the CDN-hop-count TTL), have it as a MAY in = Initial scope, and have it reflect the objective of affecting the = request routing decision (as opposed to just dropping the request if it = takes too long to redirect). Is that alright? Francois >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: Francois Le Faucheur [mailto:flefauch@cisco.com] >> Sent: Thursday, May 26, 2011 11:38 AM >> To: Kevin J Ma >> Cc: Francois Le Faucheur; cdni@ietf.org >> Subject: Delay TTL in CDNI Request Routing (was Re: incorporating a = few >> requirements from cdni-publisher-use-cases into cdni-requirements) >>=20 >> Hi Kevin, >>=20 >> Breaking this discussion into several threads to facilitate = resolution: >>=20 >> On 25 May 2011, at 02:01, Kevin J Ma wrote: >>=20 >>> Francois, >>>=20 >>> We had discussed updating three of the requirements: >>>=20 >>> - R36 discusses limiting the number of redirects for a content = request. >>> We interpret this as a hop count? >>=20 >> Right. ie effectively limit the number of CDNs that are involved in >> cascaded redirections. >> Expected to be simple, yet achieves good things (redirection loop >> prevention, rough bounding of overall redirection time, limit number = of >> players that will share the cost/revenue of delivery,..). >>=20 >> Note that this hop count limit applies to the scenario of "recursive >> redirection" (not "iterative redirection"). >>=20 >>> For certain types of live content >>> (e.g., HLS) it might be advantageous to include a time-based = limit. >>> Can we modify the text to include an optional temporal limit? = e.g.: >>=20 >> So, the trade-off here is less obvious to me. It may not be too hard = to >> include < timestamp + TTL> knobs in the CDNI request routing = request, >> but: >> * to enforce it, you'd need all CDNs in the path to use fairly >> accurately synchronized timing (as Haibin pointed out) >> * the CDN-hop limit effectively already provides a very rough = form >> of control on redirection time (albeit less accurate) >> * a delay TTL could always be autonomously enforced by the most- >> upstream CDN (i.e. when it gets the final CDNI Request Routing = response >> that has travelled through all CDNs) without any specific mechanisms >> inside the CDNI request routing API itself. >> * one potential value of adding a knob inside the CDNI request >> routing API is that a downstream CDN could try become smart in order = to >> minimize occurrences of requests being dropped dead (ie exceeding the >> TTL). To that end the CDN request routing systems on the redirection = path >> would have to try be smart and make judgment calls along the lines of = "oh, >> I see that this request has already lived quite a long life and is = getting >> close to its TTL, so should I try redirect at the risk of exceeding = the >> TTL and having it dropped dead, or should I overwrite my normal >> redirection policy and not reroute further and serve myself?" . This = may >> not be a trivial decision, since request routing times of the = downstream >> CDN may greatly vary and be hard to predict. So this will end up = having a >> positive value in some case, and a negative value in other cases. >>=20 >> Are you more after: >> (i) a mechanism that simply discards a response that would be = too >> old (but could be implemented autonomously by the upmost CDN) or >> (ii) a mechanisms that allows the CDNI system to avoid taking = too >> long to redirect (and "violates" its normal redirection policy when >> needed)? >>=20 >> If the latter, are you more after: >> (i) avoiding the transient situations (eg one of the request = routing >> system got temporarily overloaded and is atypically slow) or >> (ii) avoiding inappropriate CDN routing policies that result in = very >> large redirection times (eg CDN1 in Europe redirects to a CDN in = Asia, >> that redirects to a CDN in America, that redirects to a CDN in = Europe,..) >> ? >>=20 >> Is this something you see as really needed in Initial Scope? or in a >> subsequent phase? >>=20 >> Thanks >>=20 >> Francois --Apple-Mail-294--440980966 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi = Francois,

 The possible lack of time synchronization brings = up a separate question
 about enforcement of signed URL = expiration and more generally content
 expiration, though, the = latter is admittedly on a much less granualar
 time = scale,

Right. I don't see a = practical issue here. Just like it is not an issue with existing HTTP = cache expiration mechanisms.

= but we can leave that digression for the moment.

 To your = later points, I was thinking about (ii) and (ii), i.e., not
=  redirecting to a downstream CDN that would probably violate the = R36
 constraint.

I = see.
But I think having a knob in the CDNI Request Routing API = would only provide value if you want to support situations = where:
= (i) redirecting some requests to a CDN would result in a = redirection time that exceeds the max redirection time for these = requests, AND
(ii) redirecting some other = requests to a CDN would NOT result in a redirection time that exceeds = the max redirection time for these requests.
Because if you = are in a situation where all requests have the same max redirection = time, then you may as well update the whole redirection policy (to no = longer redirect to the dCDN) and be done with = it. 

 It could = probably be done in other ways, but, if in a
 recursive = redirection case, the upstream CDNs have latency estimates
 for = the downstream CDNs, the aggregate estimates might be sufficient
=  for providing a more accurate TTL than just hop count, without = needing
 precise time synchronization.  Granted thats = probably a more detailed
 implementation consideration than we = want to make at this time, it is
 just to say that time = synchronization should not be the limiting factor.

 As for = implementing it at the most-upstream CDN, that is certainly an
=  option as well, but using an aggregate latency estimate might = still
 require the accumulation of data during the request = routing process.
 It may or may not affect the final protocol, = but I guess the question
 is: is a time-based TTL a valid = requirement?

 I don't think it would be unreasonable for = the initial scope, but I
 don't necessarily think it is = mandatory.

So my proposal is = to add a standalone requirement for the delay-based TTL (that is = separate from the CDN-hop-count TTL), have it as a MAY in Initial scope, = and have it reflect the objective of affecting the request routing = decision (as opposed to just dropping the request if it takes too long = to redirect).

Is that = alright?

Francois



thanx.

--  Kevin J. = Ma

-----Original = Message-----
From: Francois Le = Faucheur [mailto:flefauch@cisco.com]
Sent: Thursday, May 26, 2011 11:38 = AM
To: Kevin J = Ma
Cc: Francois Le Faucheur; = cdni@ietf.org
Subject: Delay TTL in CDNI Request Routing (was Re: = incorporating a few
requirements= from cdni-publisher-use-cases into = cdni-requirements)

Hi = Kevin,

Breaking this = discussion into several threads to facilitate = resolution:

On 25 May 2011, = at 02:01, Kevin J Ma wrote:

Francois,

We had discussed updating three = of the requirements:

- R36 discusses limiting the = number of redirects for a content = request.
  We interpret this = as a hop count?

Right. ie = effectively limit the number of CDNs that are involved = in
cascaded = redirections.
Expected to be = simple, yet achieves good things (redirection = loop
prevention, rough = bounding of overall redirection time, limit number = of
players that will share the = cost/revenue of delivery,..).

Note that this = hop count limit applies to the scenario of = "recursive
redirection" (not = "iterative redirection").

For certain types of live = content
  (e.g., HLS) it might be advantageous to = include a time-based limit.
  Can we modify the = text to include an optional temporal limit? =  e.g.:

So, the = trade-off here is less obvious to me. It may not be too hard = to
include < timestamp + =  TTL> knobs in the CDNI request routing = request,
but:
* to = enforce it, you'd need all CDNs in the path to use = fairly
accurately synchronized = timing (as Haibin pointed out)
= * the CDN-hop limit effectively already provides a very rough = form
of control on redirection = time (albeit less accurate)
= * a delay TTL could always be autonomously enforced by the = most-
upstream CDN (i.e. when = it gets the final CDNI Request Routing = response
that has travelled = through all CDNs) without any specific = mechanisms
inside the CDNI = request routing API itself.
= * one potential value of adding a knob inside the CDNI = request
routing API is that a = downstream CDN could try become smart in order = to
minimize occurrences of = requests being dropped dead (ie exceeding = the
TTL). To that end the CDN = request routing systems on the redirection = path
would have to try be = smart and make judgment calls along the lines of = "oh,
I see that this request = has already lived quite a long life and is = getting
close to its TTL, so = should I try redirect at the risk of exceeding = the
TTL and having it dropped = dead, or should I overwrite my normal
redirection policy and not reroute further and serve = myself?" . This may
not be a = trivial decision, since request routing times of the = downstream
CDN may greatly = vary and be hard to predict. So this will end up having = a
positive value in some case, = and a negative value in other cases.

Are you more = after:
(i) a = mechanism that simply discards a response that would be = too
old (but could be = implemented autonomously by the upmost CDN) = or
(ii) a = mechanisms that allows the CDNI system to avoid taking = too
long to redirect (and = "violates" its normal redirection policy = when
needed)?

If the latter, = are you more after:
(i) = avoiding the transient situations (eg one of the request = routing
system got temporarily = overloaded and is atypically slow) or
= (ii) avoiding inappropriate CDN routing policies that result in = very
large redirection times = (eg CDN1 in Europe redirects to a CDN in = Asia,
that redirects to a CDN = in America, that redirects to a CDN in = Europe,..)
?

Is this = something you see as really needed in Initial Scope? or in = a
subsequent = phase?

Thanks

Francois

Subject: Re: [CDNi] Delay TTL in CDNI Request Routing (was Re: incorporating a few requirements from cdni-publisher-use-cases into cdni-requirements) 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, 27 May 2011 04:46:02 -0000 Francois, comments inline: > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Thursday, May 26, 2011 1:34 PM > To: Kevin J Ma > Cc: Francois Le Faucheur; cdni@ietf.org > Subject: Re: Delay TTL in CDNI Request Routing (was Re: incorporating a > few requirements from cdni-publisher-use-cases into cdni-requirements) >=20 >=20 > On 26 May 2011, at 18:34, Kevin J Ma wrote: >=20 >=20 > Hi Francois, >=20 > =A0The possible lack of time synchronization brings up a separate questio= n > =A0about enforcement of signed URL expiration and more generally content > =A0expiration, though, the latter is admittedly on a much less granualar > =A0time scale, >=20 > Right. I don't see a practical issue here. Just like it is not an issue > with existing HTTP cache expiration mechanisms. >=20 >=20 > but we can leave that digression for the moment. >=20 > =A0To your later points, I was thinking about (ii) and (ii), i.e., not > =A0redirecting to a downstream CDN that would probably violate the R36 > =A0constraint. >=20 > I see. > But I think having a knob in the CDNI Request Routing API would only > provide value if you want to support situations where: > (i) redirecting some requests to a CDN would result in a redirection > time that exceeds the max redirection time for these requests, AND > (ii)=A0redirecting some other requests to a CDN would NOT result in a > redirection time that exceeds the max redirection time for these requests= . > Because if you are in a situation where all requests have the same max > redirection time, then you may as well update the whole redirection polic= y > (to no longer redirect to the dCDN) and be done with it. This is probably true for a given CDN, if we ignore the transient latency c= ase (though maybe the transient latency case is valid). However, there may be = many uCDNs which service User Agent requests, each with its own redirection prio= rities based on proximity, business rules, etc. Note, I am still not convinced th= at a single authoritative CDN receiving all initial requests makes sense. There= may be a need for regional aCDNs to optimize proximity, or subscriber home aCDN= s to meeting billing or other business requirements. Coordinating redirection p= olicies between multiple aCDNs may be difficult. Having an abstraction for a laten= cy metric on which redirection decisions may be made seems useful. > =A0It could probably be done in other ways, but, if in a > =A0recursive redirection case, the upstream CDNs have latency estimates > =A0for the downstream CDNs, the aggregate estimates might be sufficient > =A0for providing a more accurate TTL than just hop count, without needing > =A0precise time synchronization. =A0Granted thats probably a more detaile= d > =A0implementation consideration than we want to make at this time, it is > =A0just to say that time synchronization should not be the limiting facto= r. >=20 > =A0As for implementing it at the most-upstream CDN, that is certainly an > =A0option as well, but using an aggregate latency estimate might still > =A0require the accumulation of data during the request routing process. > =A0It may or may not affect the final protocol, but I guess the question > =A0is: is a time-based TTL a valid requirement? >=20 > =A0I don't think it would be unreasonable for the initial scope, but I > =A0don't necessarily think it is mandatory. >=20 > So my proposal is to=A0add a standalone requirement for the delay-based T= TL > (that is separate from the CDN-hop-count TTL), have it as a MAY in Initia= l > scope, and have it reflect the objective of affecting the request routing > decision (as opposed to just dropping the request if it takes too long to > redirect). >=20 > Is that alright? That sounds fine to me. thanx! -- Kevin J. Ma > Francois >=20 >=20 >=20 >=20 > thanx. >=20 > -- =A0Kevin J. Ma >=20 >=20 > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Thursday, May 26, 2011 11:38 AM > To: Kevin J Ma > Cc: Francois Le Faucheur; cdni@ietf.org > Subject: Delay TTL in CDNI Request Routing (was Re: incorporating a few > requirements from cdni-publisher-use-cases into cdni-requirements) >=20 > Hi Kevin, >=20 > Breaking this discussion into several threads to facilitate resolution: >=20 > On 25 May 2011, at 02:01, Kevin J Ma wrote: >=20 > Francois, >=20 > We had discussed updating three of the requirements: >=20 > - R36 discusses limiting the number of redirects for a content request. > =A0=A0We interpret this as a hop count? >=20 > Right. ie effectively limit the number of CDNs that are involved in > cascaded redirections. > Expected to be simple, yet achieves good things (redirection loop > prevention, rough bounding of overall redirection time, limit number of > players that will share the cost/revenue of delivery,..). >=20 > Note that this hop count limit applies to the scenario of "recursive > redirection" (not "iterative redirection"). >=20 > For certain types of live content > =A0=A0(e.g., HLS) it might be advantageous to include a time-based limit. > =A0=A0Can we modify the text to include an optional temporal limit? =A0e.= g.: >=20 > So, the trade-off here is less obvious to me. It may not be too hard to > include < timestamp + =A0TTL> knobs in the CDNI request routing request, > but: > * to enforce it, you'd need all CDNs in the path to use fairly > accurately synchronized timing (as Haibin pointed out) > * the CDN-hop limit effectively already provides a very rough form > of control on redirection time (albeit less accurate) > * a delay TTL could always be autonomously enforced by the most- > upstream CDN (i.e. when it gets the final CDNI Request Routing response > that has travelled through all CDNs) without any specific mechanisms > inside the CDNI request routing API itself. > * one potential value of adding a knob inside the CDNI request > routing API is that a downstream CDN could try become smart in order to > minimize occurrences of requests being dropped dead (ie exceeding the > TTL). To that end the CDN request routing systems on the redirection path > would have to try be smart and make judgment calls along the lines of "oh= , > I see that this request has already lived quite a long life and is gettin= g > close to its TTL, so should I try redirect at the risk of exceeding the > TTL and having it dropped dead, or should I overwrite my normal > redirection policy and not reroute further and serve myself?" . This may > not be a trivial decision, since request routing times of the downstream > CDN may greatly vary and be hard to predict. So this will end up having a > positive value in some case, and a negative value in other cases. >=20 > Are you more after: > (i) a mechanism that simply discards a response that would be too > old (but could be implemented autonomously by the upmost CDN) or > (ii) a mechanisms that allows the CDNI system to avoid taking too > long to redirect (and "violates" its normal redirection policy when > needed)? >=20 > If the latter, are you more after: > (i) avoiding the transient situations (eg one of the request routing > system got temporarily overloaded and is atypically slow) or > (ii) avoiding inappropriate CDN routing policies that result in very > large redirection times (eg CDN1 in Europe redirects to a CDN in Asia, > that redirects to a CDN in America, that redirects to a CDN in Europe,..) > ? >=20 > Is this something you see as really needed in Initial Scope? or in a > subsequent phase? >=20 > Thanks >=20 > Francois >=20 From ietfdbh@comcast.net Fri May 27 08:48:08 2011 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 865A7E080C for ; Fri, 27 May 2011 08:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+-ruGLls0I3 for ; Fri, 27 May 2011 08:48:08 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id BE36CE080D for ; Fri, 27 May 2011 08:48:07 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta14.westchester.pa.mail.comcast.net with comcast id ofkn1g0031HzFnQ5Efo8fA; Fri, 27 May 2011 15:48:08 +0000 Received: from davidPC ([67.189.235.106]) by omta14.westchester.pa.mail.comcast.net with comcast id ofo31g01Q2JQnJT3afo55o; Fri, 27 May 2011 15:48:05 +0000 From: "David Harrington" To: References: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan><89197B0A-FBB5-4EDC-B6FB-D7BE43BE27D7@standardstrack.com> In-Reply-To: Date: Fri, 27 May 2011 11:47:52 -0400 Message-ID: <8A16CD16670843A28B0078408978E2B6@davidPC> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0269_01CC1C63.EA560DF0" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-Index: AcwbvrAnk+dWAQjHRTuvV8BTMsLULAAxXkPw Subject: [CDNi] cdni status 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, 27 May 2011 15:48:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0269_01CC1C63.EA560DF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is a status update from your Responsible AD. 1) The IESG has discussed where a CDNI WG would be best located. It was decided that, if approved, CDNI WG belonged in the TSV area and I would remain the Responsible area director. 2) I have requested the IESG discuss the proposed WG charter in the IESG telechat 6/9. 3) I have asked the BOF chairs to request a BOF session at ietf81 Quebec. This ensures the CDNI community will have a session at ietf81. 4) If the IESG approves the WG, the BOF session will simply become a WG session. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) ------=_NextPart_000_0269_01CC1C63.EA560DF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
This=20 is a status update from your Responsible AD.
 
1) The=20 IESG has discussed where a CDNI WG would be best located. It was decided = that,=20 if approved, CDNI WG belonged in the TSV area and I would remain the = Responsible=20 area director.
 
2) I=20 have requested the IESG discuss the proposed WG charter in the IESG = telechat=20 6/9.
 
3) I=20 have asked the BOF chairs to request a BOF session at ietf81 Quebec. = This=20 ensures the CDNI community will have a session at = ietf81.
 
4) If=20 the IESG approves the WG, the BOF session will simply become a WG=20 session.
 
 
David = Harrington
Director,=20 IETF Transport Area
ietfdbh@comcast.net (preferred for=20 ietf)
dbharrington@huaweisymantec.com
+1 603 828 1401 = (cell)=20
------=_NextPart_000_0269_01CC1C63.EA560DF0-- From vumip1@gmail.com Fri May 27 11:35:31 2011 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 AFF8CE0838 for ; Fri, 27 May 2011 11:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBusuAnHML-5 for ; Fri, 27 May 2011 11:35:31 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E6DF6E06F5 for ; Fri, 27 May 2011 11:35:30 -0700 (PDT) Received: by gwb20 with SMTP id 20so1133610gwb.31 for ; Fri, 27 May 2011 11:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1ToSBKIki+DlYqW/kQVPNdrjd69/rqEmuMUhQnOvyOA=; b=aOYQBD7M6QwfS9gyX2oba60tu3Oa+MkLwdMUn7FI8xb+ABYaqFwRelKBUlVCqAcKHT Lo5yPb7qwlee81PkS8GV8OFWTApCVsLix5/3RzcchjTGCaJsKoUvsGUpfsLgHXDC90nL z7Lp7XEictootsQFoVWG+S1G//0XzUoLZFYmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xoCD6vImuFIEAZhbFX3UOQW7NzEu8C8bndb6CXM+Wsp6UUhLBOp4yYM84/9w38JDJG V0HucsjxigC8vuqTYPE2PnT/w6y8MF6chOBg+XQdKzB6axYLugPx3eiiN4COM26aKnMz 7xdcONY1eaE6BPbOaDgNMR05CQgfXjRNJFrys= MIME-Version: 1.0 Received: by 10.236.63.136 with SMTP id a8mr3324462yhd.339.1306521330238; Fri, 27 May 2011 11:35:30 -0700 (PDT) Received: by 10.236.136.70 with HTTP; Fri, 27 May 2011 11:35:30 -0700 (PDT) In-Reply-To: <8A16CD16670843A28B0078408978E2B6@davidPC> References: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> <89197B0A-FBB5-4EDC-B6FB-D7BE43BE27D7@standardstrack.com> <8A16CD16670843A28B0078408978E2B6@davidPC> Date: Fri, 27 May 2011 14:35:30 -0400 Message-ID: From: Bhumip Khasnabish To: David Harrington Content-Type: multipart/alternative; boundary=00248c6a8466c7c47604a4463361 Cc: cdni@ietf.org Subject: Re: [CDNi] cdni status 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, 27 May 2011 18:35:31 -0000 --00248c6a8466c7c47604a4463361 Content-Type: text/plain; charset=ISO-8859-1 Hi David, Accordinig to Fig.1 of http://tools.ietf.org/html/draft-jenkins-cdni-problem-statement-01 (shown below) acquisition looks like out of scope of CDNI problem area. Would that remain the case going forward? Thanks. Bhumip - ------- / \ | CSP | \ / -------- * * * /\ * / \ --------------------- |CDNI| --------------------- / Upstream CDN \ | | / Downstream CDN \ | +-------------+ | Control API | +-------------+ | | |CDN Control |<======|====|=======>| CDN Control | | | +------*-*-*--+ | | | | +-*-*-*-------+ | | * * * | | | | * * * | | +------*------+ | Logging API | +-----*-------+ | | ****| Logging |<======|====|=======>| Logging |**** | | * --------------+ | | | | +-------------+ * | | * * * | | | | * * * | | * +--------*----+ | Req-Routing API | +---*---------+ * | | * **|Req-Routing |<======|====|=======>| Req-Routing |** * | | * * +-------------+ | | | | +-------------+ * * | | * * * | | | | * * * | | * * +----------*--+ |CDNI Metadata API| +-*-----------+ * * | | * * |Distribution |<======|====|=======>| Distribution| * * | | * * | | | \ / | | | * * | | * * | | | \/ | | | * * | | * ****+---------+ | | | | +---------+**** * | | ******|Surrogate|*************************|Surrogate|****** | | | +---------+ | | Acquisition | | +-----*---+ | | | +-------------+ | | +-------*-----+ | \ / \ * / --------------------- ---------*----------- * * Delivery * +------+ | User | | Agent| +------+ On Fri, May 27, 2011 at 11:47 AM, David Harrington wrote: > Hi, > > This is a status update from your Responsible AD. > > 1) The IESG has discussed where a CDNI WG would be best located. It was > decided that, if approved, CDNI WG belonged in the TSV area and I would > remain the Responsible area director. > > 2) I have requested the IESG discuss the proposed WG charter in the IESG > telechat 6/9. > > 3) I have asked the BOF chairs to request a BOF session at ietf81 Quebec. > This ensures the CDNI community will have a session at ietf81. > > 4) If the IESG approves the WG, the BOF session will simply become a WG > session. > > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > --00248c6a8466c7c47604a4463361 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PGRpdj5IaSBEYXZpZCw8L2Rpdj4KPGRpdj6gPC9kaXY+CjxkaXY+QWNjb3JkaW5pZyB0byBGaWcu MSBvZiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qZW5raW5zLWNk bmktcHJvYmxlbS1zdGF0ZW1lbnQtMDEiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWplbmtpbnMtY2RuaS1wcm9ibGVtLXN0YXRlbWVudC0wMTwvYT6gKHNob3duIGJlbG93KaAgYWNx dWlzaXRpb24gbG9va3MgbGlrZSBvdXQgb2Ygc2NvcGUgb2YgQ0ROSSBwcm9ibGVtIGFyZWEuIFdv dWxkIHRoYXQgcmVtYWluIHRoZSBjYXNlIGdvaW5nIGZvcndhcmQ/IFRoYW5rcy48L2Rpdj4KCjxk aXY+oDwvZGl2Pgo8ZGl2PkJodW1pcDwvZGl2Pgo8ZGl2PqA8L2Rpdj4KPGRpdj6goCAtPC9kaXY+ CjxkaXY+oDwvZGl2Pgo8ZGl2Pi0tLS0tLS08YnI+oKCgoCAvoKCgoKCgoCBcPGJyPqCgoKAgfKCg IENTUKAgfDxicj6goKCgIFygoKCgoKCgIC88YnI+oKCgoKAgLS0tLS0tLS08YnI+oKCgoKCgoKCg ICo8YnI+oKCgoKCgoKCgICo8YnI+oKCgoKCgoKCgICqgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCAv XDxicj6goKCgoKCgoKAgKqCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgL6AgXDxicj6goKCgoCAtLS0t LS0tLS0tLS0tLS0tLS0tLS2goKCgoCB8Q0ROSXygoKCgoKAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPgqgoKCgIC+goKAgVXBzdHJlYW0gQ0ROoKCgoCBcoKCgoCB8oKCgIHygoKCgoCAvoKAgRG93 bnN0cmVhbSBDRE6goKAgXDxicj6goKCgIHygoKCgICstLS0tLS0tLS0tLS0tKyB8oKAgQ29udHJv bCBBUEmgoCB8ICstLS0tLS0tLS0tLS0tK6CgoKAgfDxicj6goKCgIHygoKCgIHxDRE4gQ29udHJv bKAgfCZsdDs9PT09PT18PT09PXw9PT09PT09Jmd0O3wgQ0ROIENvbnRyb2wgfKCgoKAgfDxicj4K oKCgoCB8oKCgoCArLS0tLS0tKi0qLSotLSsgfKCgoKAgfKCgoCB8oKCgoKAgfCArLSotKi0qLS0t LS0tLSugoKCgIHw8YnI+oKCgoCB8oKCgoKCgoKCgoKAgKiAqICqgoKAgfKCgoKAgfKCgoCB8oKCg oKAgfKCgICogKiAqoKCgoKCgoKCgoKCgIHw8YnI+oKCgoCB8oKCgoCArLS0tLS0tKi0tLS0tLSsg fKCgIExvZ2dpbmcgQVBJoKAgfCArLS0tLS0qLS0tLS0tLSugoKCgIHw8YnI+oKCgoCB8ICoqKip8 IExvZ2dpbmegoKCgIHwmbHQ7PT09PT09fD09PT18PT09PT09PSZndDt8oCBMb2dnaW5noKCgIHwq KioqIHw8YnI+CqCgoKAgfCAqoKAgLS0tLS0tLS0tLS0tLS0rIHygoKCgIHygoKAgfKCgoKCgIHwg Ky0tLS0tLS0tLS0tLS0roKAgKiB8PGJyPqCgoKAgfCAqoKCgoKCgoKCgoKAgKiAqoKCgIHygoKCg IHygoKAgfKCgoKCgIHygoCAqICqgoKCgoKCgoKCgoKAgKiB8PGJyPqCgoKAgfCAqoKAgKy0tLS0t LS0tKi0tLS0rIHwgUmVxLVJvdXRpbmcgQVBJIHwgKy0tLSotLS0tLS0tLS0roKAgKiB8PGJyPqCg oKAgfCAqICoqfFJlcS1Sb3V0aW5noCB8Jmx0Oz09PT09PXw9PT09fD09PT09PT0mZ3Q7fCBSZXEt Um91dGluZyB8KiogKiB8PGJyPgqgoKCgIHwgKiAqICstLS0tLS0tLS0tLS0tKyB8oKCgoCB8oKCg IHygoKCgoCB8ICstLS0tLS0tLS0tLS0tKyAqICogfDxicj6goKCgIHwgKiAqoKCgoKCgoKCgoKAg KqCgoCB8oKCgoCB8oKCgIHygoKCgoCB8oKAgKqCgoKCgoKCgoKCgoCAqICogfDxicj6goKCgIHwg KiAqICstLS0tLS0tLS0tKi0tKyB8Q0ROSSBNZXRhZGF0YSBBUEl8ICstKi0tLS0tLS0tLS0tKyAq ICogfDxicj6goKCgIHwgKiAqIHxEaXN0cmlidXRpb24gfCZsdDs9PT09PT18PT09PXw9PT09PT09 Jmd0O3wgRGlzdHJpYnV0aW9ufCAqICogfDxicj4KoKCgoCB8ICogKiB8oKCgoKCgoKCgoKCgIHwg fKCgoKCgIFygIC+goKCgoKAgfCB8oKCgoKCgoKCgoKCgIHwgKiAqIHw8YnI+oKCgoCB8ICogKiB8 oKCgoKCgoKCgoKCgIHwgfKCgoKCgoCBcL6CgoKCgoKAgfCB8oKCgoKCgoKCgoKCgIHwgKiAqIHw8 YnI+oKCgoCB8ICogKioqKistLS0tLS0tLS0rIHwgfKCgoKCgoKCgoKCgoKCgoKAgfCB8ICstLS0t LS0tLS0rKioqKiAqIHw8YnI+oKCgoCB8ICoqKioqKnxTdXJyb2dhdGV8KioqKioqKioqKioqKioq KioqKioqKioqKnxTdXJyb2dhdGV8KioqKioqIHw8YnI+CqCgoKAgfKCgoKAgfCArLS0tLS0tLS0t KyB8IHygoCBBY3F1aXNpdGlvbqCgIHwgfCArLS0tLS0qLS0tKyB8oKCgoCB8PGJyPqCgoKAgfKCg oKAgKy0tLS0tLS0tLS0tLS0rIHygoKCgoKCgoKCgoKCgoKCgIHwgKy0tLS0tLS0qLS0tLS0roKCg oCB8PGJyPqCgoKAgXKCgoKCgoKCgoKCgoKCgoKCgoKCgIC+goKCgoKCgoKCgoKCgoKCgIFygoKCg oKCgoCAqoKCgoKCgoKCgoCAvPGJyPqCgoKCgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLaCgoKCgoKCg oKCgoKCgoKCgoCAtLS0tLS0tLS0qLS0tLS0tLS0tLS08YnI+CqCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCAqPGJyPqCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCAqIERlbGl2ZXJ5PGJyPqCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCAqPGJyPqCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCArLS0tLS0t Kzxicj4KoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg IHwgVXNlciB8PGJyPqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoCB8IEFnZW50fDxicj6goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKAgKy0tLS0tLSs8YnI+PGJyPjxicj48L2Rpdj4KPGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPk9uIEZyaSwgTWF5IDI3LCAyMDExIGF0IDExOjQ3IEFNLCBEYXZpZCBIYXJyaW5n dG9uIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZkYmhAY29tY2FzdC5u ZXQiPmlldGZkYmhAY29tY2FzdC5uZXQ8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPgo8YmxvY2tx dW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkOyBNQVJHSU46IDBweCAwcHgg MHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4KPGRpdiBz dHlsZT0iV09SRC1XUkFQOiBicmVhay13b3JkIj4KPGRpdj48c3Bhbj48Zm9udCBjb2xvcj0iIzAw MDBmZiIgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPkhpLDwvZm9udD48L3NwYW4+PC9kaXY+CjxkaXY+ PHNwYW4+PGZvbnQgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiIGZhY2U9IkFyaWFsIj48L2ZvbnQ+ PC9zcGFuPqA8L2Rpdj4KPGRpdj48c3Bhbj48Zm9udCBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiIg ZmFjZT0iQXJpYWwiPlRoaXMgaXMgYSBzdGF0dXMgdXBkYXRlIGZyb20geW91ciBSZXNwb25zaWJs ZSBBRC48L2ZvbnQ+PC9zcGFuPjwvZGl2Pgo8ZGl2PjxzcGFuPjxmb250IGNvbG9yPSIjMDAwMGZm IiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+PC9mb250Pjwvc3Bhbj6gPC9kaXY+CjxkaXY+PHNwYW4+ CjxkaXY+PHNwYW4+PGZvbnQgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiIGZhY2U9IkFyaWFsIj4x KSBUaGUgSUVTRyBoYXMgZGlzY3Vzc2VkIHdoZXJlIGEgQ0ROSSBXRyB3b3VsZCBiZSBiZXN0IGxv Y2F0ZWQuIEl0IHdhcyBkZWNpZGVkIHRoYXQsIGlmIGFwcHJvdmVkLCBDRE5JIFdHIGJlbG9uZ2Vk IGluIHRoZSBUU1YgYXJlYSBhbmQgSSB3b3VsZCByZW1haW4gdGhlIFJlc3BvbnNpYmxlIGFyZWEg ZGlyZWN0b3IuPC9mb250Pjwvc3Bhbj48L2Rpdj4KCjxkaXY+PHNwYW4+PGZvbnQgY29sb3I9IiMw MDAwZmYiIHNpemU9IjIiIGZhY2U9IkFyaWFsIj48L2ZvbnQ+PC9zcGFuPqA8L2Rpdj48L3NwYW4+ PC9kaXY+CjxkaXY+PHNwYW4+PGZvbnQgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiIGZhY2U9IkFy aWFsIj4yKSBJIGhhdmUgcmVxdWVzdGVkIHRoZSBJRVNHIGRpc2N1c3MgdGhlIHByb3Bvc2VkIFdH IGNoYXJ0ZXIgaW4gdGhlIElFU0cgdGVsZWNoYXQgNi85LjwvZm9udD48L3NwYW4+PC9kaXY+Cjxk aXY+PHNwYW4+PGZvbnQgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiIGZhY2U9IkFyaWFsIj48L2Zv bnQ+PC9zcGFuPqA8L2Rpdj4KPGRpdj48c3Bhbj48Zm9udCBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0i MiIgZmFjZT0iQXJpYWwiPjMpIEkgaGF2ZSBhc2tlZCB0aGUgQk9GIGNoYWlycyB0byByZXF1ZXN0 IGEgQk9GIHNlc3Npb24gYXQgaWV0ZjgxIFF1ZWJlYy4gVGhpcyBlbnN1cmVzIHRoZSBDRE5JIGNv bW11bml0eSB3aWxsIGhhdmUgYSBzZXNzaW9uIGF0IGlldGY4MS48L2ZvbnQ+PC9zcGFuPjwvZGl2 Pgo8ZGl2PjxzcGFuPjxmb250IGNvbG9yPSIjMDAwMGZmIiBzaXplPSIyIiBmYWNlPSJBcmlhbCI+ PC9mb250Pjwvc3Bhbj6gPC9kaXY+CjxkaXY+PHNwYW4+PGZvbnQgY29sb3I9IiMwMDAwZmYiIHNp emU9IjIiIGZhY2U9IkFyaWFsIj40KSBJZiB0aGUgSUVTRyBhcHByb3ZlcyB0aGUgV0csIHRoZSBC T0Ygc2Vzc2lvbiB3aWxsIHNpbXBseSBiZWNvbWUgYSBXRyBzZXNzaW9uLjwvZm9udD48L3NwYW4+ PC9kaXY+CjxkaXY+PHNwYW4+PGZvbnQgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiIGZhY2U9IkFy aWFsIj48L2ZvbnQ+PC9zcGFuPqA8L2Rpdj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+CjxkaXY+PHNw YW4+PC9zcGFuPjxzcGFuPjxmb250IGNvbG9yPSIjMDAwMGZmIiBzaXplPSIyIiBmYWNlPSJBcmlh bCI+PC9mb250Pjwvc3Bhbj6gPC9kaXY+CjxkaXY+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+RGF2aWQg SGFycmluZ3Rvbjxicj5EaXJlY3RvciwgSUVURiBUcmFuc3BvcnQgQXJlYTxicj48YSBocmVmPSJt YWlsdG86aWV0ZmRiaEBjb21jYXN0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmlldGZkYmhAY29tY2Fz dC5uZXQ8L2E+IChwcmVmZXJyZWQgZm9yIGlldGYpPGJyPjxhIGhyZWY9Im1haWx0bzpkYmhhcnJp bmd0b25AaHVhd2Vpc3ltYW50ZWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGJoYXJyaW5ndG9uQGh1 YXdlaXN5bWFudGVjLmNvbTwvYT48YnI+CjxhIGhyZWY9InRlbDolMkIxJTIwNjAzJTIwODI4JTIw MTQwMSIgdGFyZ2V0PSJfYmxhbmsiIHZhbHVlPSIrMTYwMzgyODE0MDEiPisxIDYwMyA4MjggMTQw MTwvYT4gKGNlbGwpPC9mb250PiA8L3NwYW4+PC9kaXY+PC9mb250PjwvZGl2Pjxicj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5DRE5pIG1haWxpbmcg bGlzdDxicj48YSBocmVmPSJtYWlsdG86Q0ROaUBpZXRmLm9yZyI+Q0ROaUBpZXRmLm9yZzwvYT48 YnI+CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Ru aTwvYT48YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+oAo= --00248c6a8466c7c47604a4463361-- From flefauch@cisco.com Sun May 29 23:40:41 2011 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 4C103E0766 for ; Sun, 29 May 2011 23:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.758 X-Spam-Level: X-Spam-Status: No, score=-9.758 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oblx5zAECiZi for ; Sun, 29 May 2011 23:40:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 58B69E0720 for ; Sun, 29 May 2011 23:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=17940; q=dns/txt; s=iport; t=1306737639; x=1307947239; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=3zQHbjvU4JBCy1pxALt6A4W6NoBdM5LfNsqQJPQPPbc=; b=YKdN353FFwexEFRi2WtDlXwmAFhfd+cGdamcDULy90XPoZwcw4Y0hKvP z5YRTlrnCtWWjaWQnsu9zi1i5O11Lc4IMZc1lTvCIXbVHhtycMXyhL1hR ZXBxI0jVqMDo37SK0MeH5/qmCuQBChdb5y/jsy79gpnBtspJPlU8/pTiC M=; X-IronPort-AV: E=Sophos;i="4.65,290,1304294400"; d="scan'208,217";a="91334522" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 30 May 2011 06:40:38 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4U6eaC3004481; Mon, 30 May 2011 06:40:37 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-472--134434041 From: Francois Le Faucheur In-Reply-To: Date: Mon, 30 May 2011 08:42:43 +0200 Message-Id: References: <291CC3F9E50E7641901A54E85D0977C6518BAC25E4@MAILR002.mail.lan> <89197B0A-FBB5-4EDC-B6FB-D7BE43BE27D7@standardstrack.com> <8A16CD16670843A28B0078408978E2B6@davidPC> To: Bhumip Khasnabish X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] cdni status 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, 30 May 2011 06:40:41 -0000 --Apple-Mail-472--134434041 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Bhumip, On 27 May 2011, at 20:35, Bhumip Khasnabish wrote: > Hi David, > =20 > Accordinig to Fig.1 of = http://tools.ietf.org/html/draft-jenkins-cdni-problem-statement-01 = (shown below) acquisition looks like out of scope of CDNI problem area. Just to be clear, the problem statement argues that there already exist = protocols that can be used "as is" (without any extensions) for = acquisition across CDNs, so there is no need for this group to work on = this aspect of the problem (at least initially). However, the problem = statement also indicates that potential exchange of information across = CDNs in order to bootstrap/facilitate/allow such acquisition to happen, = is in scope: for example the CDNI interfaces could convey, to the = downstream CDN, information about where the content can be acquired. > Would that remain the case going forward? Thanks. This remained the proposal to the IESG. Dave can let us know if the IESG wants to change that for some reason. Cheers Francois > =20 > Bhumip > =20 > - > =20 > ------- > / \ > | CSP | > \ / > -------- > * > * > * /\ > * / \ > --------------------- |CDNI| --------------------- > / Upstream CDN \ | | / Downstream CDN \ > | +-------------+ | Control API | +-------------+ | > | |CDN Control |<=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D|=3D=3D=3D=3D=3D= =3D=3D>| CDN Control | | > | +------*-*-*--+ | | | | +-*-*-*-------+ | > | * * * | | | | * * * | > | +------*------+ | Logging API | +-----*-------+ | > | ****| Logging |<=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D|=3D=3D=3D=3D=3D= =3D=3D>| Logging |**** | > | * --------------+ | | | | +-------------+ * | > | * * * | | | | * * * | > | * +--------*----+ | Req-Routing API | +---*---------+ * | > | * **|Req-Routing |<=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D|=3D=3D=3D=3D=3D= =3D=3D>| Req-Routing |** * | > | * * +-------------+ | | | | +-------------+ * * | > | * * * | | | | * * * | > | * * +----------*--+ |CDNI Metadata API| +-*-----------+ * * | > | * * |Distribution |<=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D|=3D=3D=3D=3D=3D= =3D=3D>| Distribution| * * | > | * * | | | \ / | | | * * | > | * * | | | \/ | | | * * | > | * ****+---------+ | | | | +---------+**** * | > | ******|Surrogate|*************************|Surrogate|****** | > | | +---------+ | | Acquisition | | +-----*---+ | | > | +-------------+ | | +-------*-----+ | > \ / \ * / > --------------------- ---------*----------- > * > * Delivery > * > +------+ > | User | > | Agent| > +------+ >=20 >=20 > On Fri, May 27, 2011 at 11:47 AM, David Harrington = wrote: > Hi, > =20 > This is a status update from your Responsible AD. > =20 > 1) The IESG has discussed where a CDNI WG would be best located. It = was decided that, if approved, CDNI WG belonged in the TSV area and I = would remain the Responsible area director. > =20 > 2) I have requested the IESG discuss the proposed WG charter in the = IESG telechat 6/9. > =20 > 3) I have asked the BOF chairs to request a BOF session at ietf81 = Quebec. This ensures the CDNI community will have a session at ietf81. > =20 > 4) If the IESG approves the WG, the BOF session will simply become a = WG session. > =20 > =20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail-472--134434041 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Bhumip,

On 27 May 2011, at 20:35, Bhumip Khasnabish = wrote:

Hi David,
 
Accordinig to Fig.1 of http://tools.ietf.org/html/draft-jenkins-cdni-problem-statement-01&n= bsp;(shown below)  acquisition looks like out of scope of CDNI = problem area.

Just to be clear, = the problem statement argues that there already exist protocols that can = be used "as is" (without any extensions) for acquisition across CDNs, so = there is no need for this group to work on this aspect of the problem = (at least initially). However, the problem statement also indicates that = potential exchange of information across CDNs in order to = bootstrap/facilitate/allow such acquisition to happen, is in scope: for = example the CDNI interfaces could convey, to the downstream CDN, = information about where the content can be = acquired.


Would = that remain the case going forward? Thanks.

This remained the proposal to the = IESG.
Dave can let us know if the IESG wants to change that = for some = reason.

Cheers

Francois<= /div>
 
Bhumip
 
   -
 
-------
     = /        = \
     |   CSP  = |
     = \        = /
      = --------
          = *
          = *
          = *            &= nbsp;           = /\
          = *            &= nbsp;          /  = \
      = ---------------------      = |CDNI|       ---------------------
     /    Upstream = CDN     \     = |    |      /   = Downstream CDN    \
     = |     +-------------+ |   Control = API   | +-------------+     = |
     |     |CDN = Control  |<=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D&g= t;| CDN Control |     |
     |     +------*-*-*--+ = |     |    = |      | = +-*-*-*-------+     |
     = |            * * = *    |     |    = |      |   * * = *             = |
     |     +------*------+ = |   Logging API   | = +-----*-------+     |
     | = ****| Logging     = |<=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D>|  = Logging    |**** |
     | *   --------------+ = |     |    = |      | +-------------+   * = |
     | = *            * = *    |     |    = |      |   * = *             = * |
     | *   +--------*----+ | = Req-Routing API | +---*---------+   * = |
     | * **|Req-Routing  = |<=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D>| = Req-Routing |** * |
     | * * +-------------+ |     = |    |      | +-------------+ * = * |
     | * = *            = *    |     |    = |      |   = *             = * * |
     | * * +----------*--+ |CDNI Metadata = API| +-*-----------+ * * |
     | * * = |Distribution |<=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D&g= t;| Distribution| * * |
     | * * = |             = | |      \  = /       | = |             = | * * |
     | * * = |             = | |       = \/        | = |             = | * * |
     | * ****+---------+ | = |            &= nbsp;    | | +---------+**** * = |
     | = ******|Surrogate|*************************|Surrogate|****** |
     |     | +---------+ | = |   Acquisition   | | +-----*---+ = |     |
     = |     +-------------+ = |            &= nbsp;    | +-------*-----+     = |
     = \            &= nbsp;        = /            &= nbsp;    = \         = *           = /
      = ---------------------         = ;          = ---------*-----------
=             &n= bsp;           &nbs= p;            =             &n= bsp;     = *
           &nb= sp;            = ;            &= nbsp;           &nb= sp;      * = Delivery
          &n= bsp;           &nbs= p;            =             &n= bsp;       = *
           &nb= sp;            = ;            &= nbsp;           &nb= sp;   +------+
=             &n= bsp;           &nbs= p;            =             &n= bsp;  | User = |
           &nb= sp;            = ;            &= nbsp;           &nb= sp;   | = Agent|
          &nbs= p;            =             &n= bsp;           &nbs= p;    +------+


On Fri, May 27, 2011 at 11:47 AM, David = Harrington <ietfdbh@comcast.net> = wrote:
Hi,
 
This is a = status update from your Responsible AD.
 
1) The IESG = has discussed where a CDNI WG would be best located. It was decided = that, if approved, CDNI WG belonged in the TSV area and I would remain = the Responsible area director.
 
2) I have = requested the IESG discuss the proposed WG charter in the IESG telechat = 6/9.
 
3) I have = asked the BOF chairs to request a BOF session at ietf81 Quebec. This = ensures the CDNI community will have a session at = ietf81.
 
4) If the = IESG approves the WG, the BOF session will simply become a WG = session.
 
 
David Harrington
Director, IETF Transport = Area
ietfdbh@comcast.net (preferred for ietf)
dbharrington@huaweisymantec.com
+1 603 828 1401 (cell) =

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


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

= --Apple-Mail-472--134434041--