From prvs=432645842=allan.guillou@sfr.com Mon Apr 2 02:27:04 2012 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 9ED9721F8858 for ; Mon, 2 Apr 2012 02:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDQApOYy6-2r for ; Mon, 2 Apr 2012 02:27:03 -0700 (PDT) Received: from mail-diffu4.sfr.fr (mail-diffu4.sfr.fr [217.70.85.111]) by ietfa.amsl.com (Postfix) with ESMTP id 0465521F8859 for ; Mon, 2 Apr 2012 02:27:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,356,1330902000"; d="scan'208,217";a="126039765" Received: from unknown (HELO EXCH002.encara.local.ads) ([10.29.105.2]) by mx4int-buro.prod with ESMTP; 02 Apr 2012 11:27:00 +0200 Received: from EXCH011.encara.local.ads (10.29.105.70) by EXCH002.encara.local.ads (10.29.105.2) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 2 Apr 2012 11:27:00 +0200 Received: from EXCN015.encara.local.ads ([fe80::f109:6a12:5ba6:f568]) by EXCH011.encara.local.ads ([::1]) with mapi id 14.02.0283.003; Mon, 2 Apr 2012 11:27:00 +0200 From: "GUILLOU, Allan" To: "'Woundy, Richard'" , "cdni@ietf.org" Thread-Topic: Footprint / capabilities advertisement design team Thread-Index: AQHNDlnczajnpWSt2katXRkXHNJFGpaC/CqAgARMTbA= Date: Mon, 2 Apr 2012 09:26:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.141.23] Content-Type: multipart/alternative; boundary="_000_C27ACEE8C2F15442A87686E0BD5878A4D4ECEXCN015encaralocala_" MIME-Version: 1.0 Subject: Re: [CDNi] Footprint / capabilities advertisement design team 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, 02 Apr 2012 09:27:04 -0000 --_000_C27ACEE8C2F15442A87686E0BD5878A4D4ECEXCN015encaralocala_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I volunteer to participate to this design team. --- Allan ________________________________ De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de Wou= ndy, Richard Envoy=E9 : vendredi 30 mars 2012 11:48 =C0 : cdni@ietf.org Objet : Re: [CDNi] Footprint / capabilities advertisement design team Re-sending to correct Jon's email address... CDNI folks, Based on today's discussion, and in the interest of making progress prior t= o our anticipated interim meeting in mid-May, Jon Peterson and Stefano Prev= idi have agreed to lead a design team focused on defining the semantics of = request routing footprint / capabilities advertisement. The focus is on sem= antics, not protocols (e.g. ALTO or BGP). Anyone willing to participate in weekly one hour conference calls is welcom= ed to join the design team. Please reach out to Jon and Stefano directly to= join; they are copied on this email. Operator feedback is especially solic= ited. -- Rich --_000_C27ACEE8C2F15442A87686E0BD5878A4D4ECEXCN015encaralocala_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I v= olunteer to participate to this design team.

 

 

---=

All= an

 

De := cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de Woundy, Richard
Envoy=E9 : vendredi 30 = mars 2012 11:48
=C0 : cdni@ietf.org
Objet : Re: [CDNi] Foot= print / capabilities advertisement design team

 

Re-sending t= o correct Jon's email address…

 <= /o:p>

CDNI folks,<= o:p>

 <= /o:p>

Based on tod= ay's discussion, and in the interest of making progress prior to our antici= pated interim meeting in mid-May, Jon Peterson and Stefano Previdi have agreed to lead a design team focused on defining = the semantics of request routing footprint / capabilities advertisement. Th= e focus is on semantics, not protocols (e.g. ALTO or BGP).

 <= /o:p>

Anyone willi= ng to participate in weekly one hour conference calls is welcomed to join t= he design team. Please reach out to Jon and Stefano directly to join; they are copied on this email. Operator feedback= is especially solicited.

 <= /o:p>

-- Rich=

--_000_C27ACEE8C2F15442A87686E0BD5878A4D4ECEXCN015encaralocala_-- From vumip1@gmail.com Tue Apr 3 19:38:11 2012 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 DEADC21F856C; Tue, 3 Apr 2012 19:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=0.773, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBQWpDA-oaDb; Tue, 3 Apr 2012 19:38:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37C8F21F8568; Tue, 3 Apr 2012 19:38:11 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so587840obb.31 for ; Tue, 03 Apr 2012 19:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6uEBZ9heJkgKZQdg8XGDIyAo9fY484LtFO+LXwB22SQ=; b=Cu4yBE1GGi/5dcs1VLoLR22aNE1Qv2js3jXoSf9I07NQruwi+Z5VDOnV7xMNmtzIRj p3aSWAOnoCMGNcxLsfUiAZKLNvXuxhUPsnfD+IXO8LumZTY0Y1e5OXVSKvH5ENEWMWo8 fJt7R9LWMqjON1LB7iiqM3amHfO7ATkUH/pMXd4kFPlS/sqi5Wh+G8OSgyJVvFYtaMGf INnv4b+RNORrsXVPdXXnlMskUpl+uAxnynFbC/dRLiQj9N5+zpx+6wHtEdp1eOrccVtJ 87z4OAskACWmZXcjQ1XwzQKtnTrdfhJVPVlBuFjUT6KR5LX9UUE8xz1OW3m5lWlTWnM4 3WpA== MIME-Version: 1.0 Received: by 10.182.188.38 with SMTP id fx6mr22118610obc.77.1333507090880; Tue, 03 Apr 2012 19:38:10 -0700 (PDT) Received: by 10.182.171.104 with HTTP; Tue, 3 Apr 2012 19:38:10 -0700 (PDT) Date: Tue, 3 Apr 2012 22:38:10 -0400 Message-ID: From: Bhumip Khasnabish To: opsawg@ietf.org, apps-discuss@ietf.org, dc@ietf.org, cdni@ietf.org, scim@ietf.org, dcrg-interest@irtf.org Content-Type: multipart/alternative; boundary=f46d04478bdd7518e904bcd150de Subject: [CDNi] Fwd: slides from IETF83 Cloud Storage Talk by Giorgio 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, 04 Apr 2012 02:38:12 -0000 --f46d04478bdd7518e904bcd150de Content-Type: text/plain; charset=ISO-8859-1 The slides from IETF83 Cloud Storage Talk by Giorgio are now available at the following Website: http://trac.tools.ietf.org/area/app/trac/wiki/Clouds File names are as follows: IETF83-Cloud-Storage-Talk-Giorgio-29Mar2012-part1.pdf and IETF83-Cloud-Storage-Talk-Giorgio-29Mar2012-part2.pdf --f46d04478bdd7518e904bcd150de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The slides from IETF83 Cloud Storage Talk by Giorgio are now available a= t the following Website:
http://trac.tools.ietf.org/area/app/tra= c/wiki/Clouds

File names are as follows:
=A0
IETF83-Cloud-Storage-Talk-Giorgio-2= 9Mar2012-part1.pdf
and
IETF83-Cloud-Storage-Talk-Giorgio-29Mar2012-= part2.pdf
=A0
=A0
=A0

--f46d04478bdd7518e904bcd150de-- From gilles.bertrand@orange.com Wed Apr 4 09:04:16 2012 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 9AAB621F8872 for ; Wed, 4 Apr 2012 09:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I19r49YC48JC for ; Wed, 4 Apr 2012 09:04:15 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id CC24921F87E1 for ; Wed, 4 Apr 2012 09:04:14 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C42E55D89A2; Wed, 4 Apr 2012 18:04:13 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id B3D5E5D89A1; Wed, 4 Apr 2012 18:04:13 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Apr 2012 18:04:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD127C.93EED03E" Date: Wed, 4 Apr 2012 18:04:13 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF0346E8D4@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4F7503C6.20205@skytide.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Comments on draft-bertrand-cdni-logging-00 Thread-Index: Ac0OD3pyFl8rf5sKRKqKXG1cJlYXdQEatbmA References: <4F7503C6.20205@skytide.com> From: To: , X-OriginalArrivalTime: 04 Apr 2012 16:04:13.0501 (UTC) FILETIME=[942FAED0:01CD127C] Subject: Re: [CDNi] Comments on draft-bertrand-cdni-logging-00 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, 04 Apr 2012 16:04:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD127C.93EED03E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roy, Thanks for these comments. 1) I agree that minimizing the number of reformatting steps is = important to provide Logging data ASAP and to limit the Logging = processing burden. I think the format of the logs must be negotiable = between the uCDN and the dCDN. So, both options (1) dCDN provides logs = in his native format and (2) dCDN provides logs in a standard format are = considered. A standard format brings value, for instance as a fallback = option if the CDNs do not support the same formats (e.g., the uCDN is = not able to handle the dCDN's native format). 2) Agreed 3) Agreed Best regards, Gilles =20 De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de = Roy Peterkofsky Envoy=E9 : vendredi 30 mars 2012 02:52 =C0 : cdni@ietf.org Objet : [CDNi] Comments on draft-bertrand-cdni-logging-00 =20 First off, by way of introduction, I head product management for = Skytide. We are a leading supplier of CDN reporting and analytics = software and thus a key consumer of CDN logs. I think this gives us a = good perspective on requirements for CDNi logging. Secondly, I am very new to the IETF working group so I apologize if my = comments are not in the customary or correct form for this. I did want = to get these to the group before you meet in Paris to discuss this = subject area so I focused my attention on making the comments timely. Anway: 1) I think there could stand to be some discussion around the impact of = even having standardized log formats for interconnected CDNs. I start = with the assumption that each individual CDN, as an independent entity, = has one (or possibly several) log file formats that it works with = internally for its own reporting, billing, etc. (call these the "native" = log file formats). What format(s) the CDN uses may well be determined = by which platform technology or technologies the CDN uses. If this CDN = is the dCDN in a particular scenario, it could either (a) ship the = relevant logs to the uCDN in their "native" format(s) or (b) first = translate them into a standardized format. Assuming that the uCDN has = its own "native" format used internally, in either case, the uCDN would = then have to translate the received logs into this native format (from = either the dCDN's native format or the standardized format). The use of = a common standardized format for all possible dCDNs, of course, will = minimize the number of translators/connectors that the uCDN must have = available (and ensure that the required data elements are always = present). But it also requires two translations to take place (dCDN = native format to standardized format to uCDN native format) while simply = sending the logs in the dCDN's native format will only require one = translation (dCDN native format to uCDN native format). In a = high-volume (e.g. ABR/HAS) scenario where reporting/analytics/monitoring = are required in real-time, the extra translation step will consume time = that is not necessarily available! Based on my work with an analytics = system that can easily ingest and parse/translate multiple log file = formats, I don't see the need to do so at the uCDN end to be a major = issue. 2) I think the specification should consider use cases for both push and = pull (or "on demand") log delivery. In the former scenario, the dCDN = would dispatch files of appropriate log records to the uCDN on some = metered basis (either every X time periods or when Y log records have = accumulated, for example). In the latter, the uCDN would request log = records meeting some set of criteria (time range at the least, possibly = other filter elements as well) from the dCDN. I was happy to see the = subject of aggregated log delivery covered, as the "on demand" scenario = for log delivery can easily be seen to have one "flavor" which returns = every individual log record and another which returns only aggregated = data. It would have to be determined which measures (e.g., request, = bytes, total duration) are aggregated and at what levels (anywhere from = grand totals at one end of the spectrum to, at the other end, = aggregation only when every other field of the log record matches). = This becomes, actually, more of a "data query" than a "log request" and = can be looked at as much as a "reporting interface" as a "logging = interface." 3) The value of the logging standards will be greatly enhanced if they = allow for (at least optional) inclusion of certain extended/custom = fields. User agent and referrer are key extensions to the standard W3C = logging formats that are of great value in CDN reporting (these are = mentioned in the document). Beyond these, the standard should describe = how additional fields can be added so that interconnected CDNs, by = mutual agreement, can pass additional data elements without having these = extended logs "break" the integration for other CDNs that are only = looking for the standard fields.=20 --=20 Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success = =20 ------_=_NextPart_001_01CD127C.93EED03E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Roy,

Thanks for these = comments.

1)      = I agree = that minimizing the number of reformatting steps is important to provide = Logging data ASAP and to limit the Logging processing burden. I think = the format of the logs must be negotiable between the uCDN and the dCDN. = So, both options (1) dCDN provides logs in his native format and (2) = dCDN provides logs in a standard format are considered. A standard = format brings value, for instance as a fallback option if the CDNs do = not support the same formats (e.g., the uCDN is not able to handle the = dCDN's native format).

2)      = Agreed

3)      = Agreed

Best regards,

Gilles

 

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowt= ext'>De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Roy Peterkofsky
Envoy=E9 : vendredi 30 mars 2012 = 02:52
=C0 : cdni@ietf.org
Objet : [CDNi] = Comments on = draft-bertrand-cdni-logging-00

 

Firs= t off, by way of introduction, I head product management for = Skytide.  We are a leading supplier of CDN reporting and analytics = software and thus a key consumer of CDN logs.  I think this gives = us a good perspective on requirements for CDNi logging.

Secondly, = I am very new to the IETF working group so I apologize if my comments = are not in the customary or correct form for this.  I did want to = get these to the group before you meet in Paris to discuss this subject = area so I focused my attention on making the comments = timely.

Anway:

1) I think there could stand to be some = discussion around the impact of even having standardized log formats for = interconnected CDNs.  I start with the assumption that each = individual CDN, as an independent entity, has one (or possibly several) = log file formats that it works with internally for its own reporting, = billing, etc. (call these the "native" log file = formats).  What format(s) the CDN uses may well be determined by = which platform technology or technologies the CDN uses.  If this = CDN is the dCDN in a particular scenario, it could either (a) ship the = relevant logs to the uCDN in their "native" format(s) or (b) = first translate them into a standardized format.  Assuming that the = uCDN has its own "native" format used internally, in either = case, the uCDN would then have to translate the received logs into this = native format (from either the dCDN's native format or the standardized = format).  The use of a common standardized format for all possible = dCDNs, of course, will minimize the number of translators/connectors = that the uCDN must have available (and ensure that the required data = elements are always present).  But it also requires two = translations to take place (dCDN native format to standardized format to = uCDN native format) while simply sending the logs in the dCDN's native = format will only require one translation (dCDN native format to uCDN = native format).  In a high-volume (e.g. ABR/HAS) scenario where = reporting/analytics/monitoring are required in real-time, the extra = translation step will consume time that is not necessarily = available!  Based on my work with an analytics system that can = easily ingest and parse/translate multiple log file formats, I don't see = the need to do so at the uCDN end to be a major issue.

2) I think = the specification should consider use cases for both push and pull (or = "on demand") log delivery.  In the former scenario, the = dCDN would dispatch files of appropriate log records to the uCDN on some = metered basis (either every X time periods or when Y log records have = accumulated, for example).  In the latter, the uCDN would request = log records meeting some set of criteria (time range at the least, = possibly other filter elements as well) from the dCDN.  I was happy = to see the subject of aggregated log delivery covered, as the "on = demand" scenario for log delivery can easily be seen to have one = "flavor" which returns every individual log record and another = which returns only aggregated data.   It would have to be = determined which measures (e.g., request, bytes, total duration) are = aggregated and at what levels (anywhere from grand totals at one end of = the spectrum to, at the other end, aggregation only when every other = field of the log record matches).  This becomes, actually, more of = a "data query" than a "log request" and can be = looked at as much as a "reporting interface" as a = "logging interface."

3) The value of the logging = standards will be greatly enhanced if they allow for (at least optional) = inclusion of certain extended/custom fields.  User agent and = referrer are key extensions to the standard W3C logging formats that are = of great value in CDN reporting (these are mentioned in the = document).  Beyond these, the standard should describe how = additional fields can be added so that interconnected CDNs, by mutual = agreement, can pass additional data elements without having these = extended logs "break" the integration for other CDNs that are = only looking for the standard fields.

-- =
Roy Peterkofsky
Vice President, Product Management
Skytide -- = the leader in Digital Media Performance Management
www.skytide.com
(510) = 250-4284

Read our new white paper: The 4 Keys to Telco CDN = Success

------_=_NextPart_001_01CD127C.93EED03E-- From RMurray@velocix.com Wed Apr 4 14:46:29 2012 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 A57A121F8582 for ; Wed, 4 Apr 2012 14:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNVtVFA5X7-X for ; Wed, 4 Apr 2012 14:46:28 -0700 (PDT) Received: from owa.velocix.com (mail-out.velocix.com [212.44.61.56]) by ietfa.amsl.com (Postfix) with ESMTP id AC19921F8512 for ; Wed, 4 Apr 2012 14:46:27 -0700 (PDT) Received: from EXB04CAM.corp.velocix.com ([169.254.1.160]) by exc01cam.corp.velocix.com ([212.44.61.56]) with mapi id 14.02.0247.003; Wed, 4 Apr 2012 22:46:03 +0100 From: Rob Murray To: Kevin J Ma , "Kent Leung (kleung)" , "cdni@ietf.org" Thread-Topic: [CDNi] CDNI Triggers interface Thread-Index: AQHM9ylJjw/I9226gUqTKwJkpHCC05Z2wCQAgARJ3wCAA+KmoIAAz+mAgAAcY3CAC5F5gA== Date: Wed, 4 Apr 2012 21:46:25 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6526087235B@MAILR002.mail.lan> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.16.16.169] Content-Type: text/plain; charset="us-ascii" Content-ID: <48B11F35F4EB264CB6B15963A5B95914@velocix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Triggers interface 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, 04 Apr 2012 21:46:29 -0000 Hi Kevin, Apologies for the delayed response, and thank you for clarifying that use case. I'd be interested to hear from others, but my initial thinking is that triggered activity is most likely to be pushed into the network quite quickly, and happen in parallel with other triggers. So, unless dCDN decides it's overloaded, each trigger will probably not spend much time in "pending" state. If that's the case, offering the appearance of finer-grained control over the scheduling may not add much. But, that said, a priority indication would be an easy thing to add to the protocol (now or later), if it's thought to be useful. The subject of trigger ordering was discussed further in Paris, outside the WG session. In particular - Matt Caulfield pointed out that in a cascade of CDNs, careful ordering of request initiation by uCDN into dCDN could be lost when dCDN passes the triggers downstream. I think we concluded that a trigger request should be allowed to contain an ordered list of triggers. Failure of any one of the triggers will be reported as failure of the whole request, and dCDN must pass on ordered triggers to its dCDNs as ordered triggers. Internally however, each CDN may still process those triggers in parallel, so the new semantics of content invalidate/purge up to the time the request was received still apply. Under this scheme, to replace some content, you'd bundle an invalidate/purge with a preposition in a single request. That eliminates the window where newly acquired content could be invalidated/purged. I'll update the draft to reflect that, and the other comments received. Many thanks, Rob. On 28/03/2012 15:40, "Kevin J Ma" wrote: >Hi Rob, > > Wrt priorities, I was thinking about a case where there are a large >number > of trigger requests, possibly initiated by end customers, e.g., the uCDN > provides a web portal to allow customers to purge/invalidate content. >Not > all customers/administrators are created equal, and not wanting to >delete, > remember, and repost every trigger, it might be useful to have >priorities. > I agree that we may not want triggers to be pre-emptive, and the dCDN >may > have its own priorities, but if a uCDN and dCDN negotiate some >understanding, > outside the scope of CDNI, would a priority field be useful? > >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: Rob Murray [mailto:RMurray@velocix.com] >> Sent: Wednesday, March 28, 2012 6:25 AM >> To: Kevin J Ma; Kent Leung (kleung); cdni@ietf.org >> Subject: Re: [CDNi] CDNI Triggers interface >>=20 >> Hi Kevin, and thanks - responses inline... >>=20 >> On 28/03/2012 02:08, "Kevin J Ma" wrote: >>=20 >> >Hi Rob, >> > >> > I think the doc does a good job of clearly defining the space. >> > I had a couple of questions: >> > >> > - Section 4.4 mentions returning 404/410 on subsequent requests for a >> > resource after deletion. I assume this also applies to section 4.3 >> > and explicit deletion? Might be worth clarifying in section 4.3? >>=20 >> Yes, will do. >>=20 >> > - Along the lines of Matt and Kent's questions about request >>ordering, >> > I was wondering about repeat requests. The current set of triggers >> > are fairly idemopotent, so perhaps it would only be an optimization >> > for them, but are there concerns for duplicate requests or requests >> > with overlapping urls/patterns wrt any pending or active triggers? >>=20 >> I think the interaction we want to avoid is between invalidate/purge and >> preposition, I hope my suggestion for using trigger "ctime" to indicate >> which data should be invalidated/purged addresses that? And, as you say, >> the current operations are fairly idempotent. >>=20 >> Each uCDN can only affect its own data, so it should be in full control >>of >> any interactions. If it asks dCDN to do something silly with overlapping >> URLs/paterns, I don't think dCDN should try to second-guess it. >>=20 >> > - For trigger creation, would it make sense to have a priority field, >> > to allow uCDNs to influence the order in which dCDNs process >> triggers? >>=20 >> Whether it's possible to influence the order of processing will depend a >> lot on the implementation in dCDN. It may or may not be possible to >> stop/pause/pace triggered activity on any given cache, or across the >> network. Allowing the uCDN to set a priority might give an illusion of >> control that it doesn't have. >>=20 >> Do you have a particular use-case in mind? One that springs to mind >>would >> be that uCDN has made a time-consuming request, then wants to inject >> something more urgent. In this case it has the option of deleting the >> original trigger (dCDN may or may not stop work on it) and re-creating >>it >> later, the idempotence of the operations helps us again there. >>=20 >> Overall, I think it's probably best to keep things simple and leave >> scheduling/ordering of triggers under uCDN control by expecting it to >>make >> requests and wait for completions in an order it likes. >>=20 >>=20 >> >thanx. >> > >> >-- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf >>Of >> >> Rob Murray >> >> Sent: Sunday, March 25, 2012 7:43 AM >> >> To: Kent Leung (kleung); cdni@ietf.org >> >> Subject: Re: [CDNi] CDNI Triggers interface >> >> >> >> Thanks Kent - replies inline ... >> >> >> >> On 22/03/2012 18:11, "Kent Leung (kleung)" wrote: >> >> >> >> >Hi Rob. Nice write-up. Here are some comments on the draft. >> >> > >> >> >1. Sect. 2: Nit for "The trigger may request action on either >>metadata >> >> >or on content". Reword to "The trigger may request action on either >> >> >metadata or content"? >> >> >> >> Will do. >> >> >> >> >2. Sect. 2: Any thoughts on the scalability aspect of using RESTful >> web >> >> >service assuming there will be many dCDNs providing delivery service >> >>for >> >> >a uCDN? These triggers will likely apply on all the dCDNs. >> >> >> >> Since uCDN has the contract with the Content Owner (or with another >> uCDN >> >> that does), it has ultimate responsibility for ensuring that triggers >> >>are >> >> acted upon - I think it will need to track which dCDNs have its data >> and >> >> which have completed its triggers, for auditing purposes if nothing >> >>else? >> >> Because it's got that responsibility, uCDN will want a way to >> >>interrogate >> >> dCDN for status of triggers so, correspondingly, dCDN will need to >> track >> >> and report state of triggers. >> >> >> >> So, I'd say per-trigger, per-interconnect state will exist at both >>ends >> >> of the interface whether it's RESTful or not. Does that answer the >> >> concern? I can add some descriptive text to the draft along those >>lines >> >>if >> >> it does. >> >> >> >> Do you have a feel for the numbers of interconnects a given CDN is >> >>likely >> >> to have? I can't find an indication in the problem-statement or >> >> requirements - but I'd imagine each CDN will have a relatively small >> >> number >> >> of interconnect agreements, perhaps up to low tens? Generally I'd >>think >> >> CDNs will have many fewer interconnects than Delivery Surrogates, but >> an >> >> exception might be a "broker" CDN that owns content but doesn't do >>the >> >> actual delivery itself. In that case, I'd guess we're not talking >>about >> >> thousands of interconnects but perhaps it might get into hundreds? I >> >> don't have any actual facts or data to cloud my thinking though (!), >>so >> >> I'd be interested to hear other views. >> >> >> >> >3. Sect. 4: Typo in "For example, is anticipated that decisions on >>use >> >> >of HTTPS for other CDNI interfaces will be adopted for Triggers." >> >> >> >> Will fix. >> >> >> >> >4. Sect. 4.1: The Trigger Request must be processed in the sequence >>as >> >> >triggered by the uCDN? Is there a message sequencing method defined? >> >>For >> >> >example, uCDN wants to purge a specific content, then preposition >>that >> >> >content. What happens when the message arrives at dCDN out of order? >> >> >> >> Good point, thanks, I've not covered that. >> >> >> >> If we define the invalidate/purge triggers to mean "invalidate or >>purge >> >> data obtained before this trigger was created" (before "ctime" of the >> >> Trigger Status Resource), I think that solves the problem. For >>example, >> >>a >> >> use-case for "invalidate" followed by "preposition" would be an >> >>emergency >> >> fix to some metadata or content - with this change, by issuing >>triggers >> >>in >> >> order after the data is repaired, uCDN can be sure incorrect data is >> >> deleted. But, data acquired from the same location after the repair >> >> (either as a result of pre-positioning or normal operation) will not >> >>need >> >> to be re-fetched. The invalidate/purge and the preposition triggers >>can >> >> run concurrently. >> >> >> >> I makes the semantics of invalidate/purge cleaner anyway. If >>(repaired) >> >> data can still obtained from affected URL, it'd be hard for uCDN to >> >> guarantee that when a purge completes no data from affected URLs >>exists >> >> in dCDN. Much easier for it to say that data acquired before a given >> >> time has been invalidated/purged from the network. >> >> >> >> >5. Sect. 4.2: Nit for ".. to cheaply check for change .." Maybe " .. >> to >> >> >inherently check for change .."? >> >> >> >> How about "... to check for change in status of a resource or >> collection >> >> of resources without re-fetching the whole resource or collection." >> >> >> >> > >> >> >6. Sect 4.2: Reword " to indicate the frequency it would like uCDN >>to >> >> >poll at." to " to indicate the frequency of polling by the uCDN"? >> >> >> >> How about "The dCDN should use the cache control headers for >>responses >> >>to >> >> GETs for Trigger Status Resources and Collections to indicate the >> >> frequency at which it recommends uCDN should poll for change." >> >> >> >> >Kent >> >> > >> >> >-----Original Message----- >> >> >From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf >> Of >> >> >Rob Murray >> >> >Sent: Wednesday, February 29, 2012 1:25 PM >> >> >To: cdni@ietf.org >> >> >Subject: [CDNi] CDNI Triggers interface >> >> > >> >> >Hi all, >> >> > >> >> >I've just uploaded a new draft that proposes a CDNI Triggers >>interface >> >> >... >> >> > >> >> > http://datatracker.ietf.org/doc/draft-murray-cdni-triggers/ >> >> > >> >> > >> >> >There was some discussion at the last WG meeting about whether >> triggers >> >> >fit best as part of the control or metadata interface - the >>suggestion >> >> >was >> >> >that concrete proposals for the interface might help us spot >> >>commonality >> >> >with one or the other, so let's see! >> >> > >> >> >Please take a look, your comments are welcome. >> >> > >> >> >Best regards, >> >> >Rob. >> >> > >> >> > >> >> >On 29/02/2012 19:37, "internet-drafts@ietf.org" >> >> > >> >> >wrote: >> >> > >> >> >>A new version of I-D, draft-murray-cdni-triggers-00.txt has been >> >> >>successfully submitted by Rob Murray and posted to the IETF >> >>repository. >> >> >> >> >> >>Filename: draft-murray-cdni-triggers >> >> >>Revision: 00 >> >> >>Title: CDN Interconnect Triggers >> >> >>Creation date: 2012-02-29 >> >> >>WG ID: Individual Submission >> >> >>Number of pages: 33 >> >> >> >> >> >>Abstract: >> >> >> This document proposes a mechanism for a CDN to trigger activity >> in >> >> >> an interconnected CDN that is configured to deliver content on >>its >> >> >> behalf. The upstream CDN can use this mechanism to request that >> >>the >> >> >> downstream CDN pre-positions metadata or content, or that it re- >> >> >> validate or purge metadata or content. The upstream CDN can >> >>monitor >> >> >> the status of activity that it has triggered in the downstream >> CDN. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>The IETF Secretariat >> >> > >> >> >_______________________________________________ >> >> >CDNi mailing list >> >> >CDNi@ietf.org >> >> >https://www.ietf.org/mailman/listinfo/cdni >> >> >> >> _______________________________________________ >> >> CDNi mailing list >> >> CDNi@ietf.org >> >> https://www.ietf.org/mailman/listinfo/cdni > From RMurray@velocix.com Wed Apr 4 14:58:37 2012 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 9F7EB11E80C2 for ; Wed, 4 Apr 2012 14:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psUst7-ISVie for ; Wed, 4 Apr 2012 14:58:36 -0700 (PDT) Received: from owa.velocix.com (host1.cachelogic.com [212.44.43.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA9311E80A2 for ; Wed, 4 Apr 2012 14:58:36 -0700 (PDT) Received: from EXB04CAM.corp.velocix.com ([169.254.1.160]) by exc02cam.corp.velocix.com ([172.16.16.133]) with mapi id 14.02.0247.003; Wed, 4 Apr 2012 22:58:34 +0100 From: Rob Murray To: "cdni@ietf.org" Thread-Topic: DNS and "diamond shaped" interconnect Thread-Index: AQHNEq4UIl09SA9t/EeaeyLatX0WAw== Date: Wed, 4 Apr 2012 21:58:34 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.16.16.169] Content-Type: text/plain; charset="us-ascii" Content-ID: <970AEAAAE8A080479FD491F34F978DC4@velocix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] DNS and "diamond shaped" interconnect 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, 04 Apr 2012 21:58:37 -0000 Hi all, In the first WG session in Paris there was some discussion about the specific case of DNS request routing where more than one uCDN is interconnected with the authoritative CDN for some content. (There's a "diamond shape" in the interconnect paths for that content.) When this happens, dCDN has no way to tell from the incoming request which uCDN selected it. So, it's not able to use that request to determine which uCDN's metadata to use, or where to send logs etc. We don't know of a technical solution to the problem, it's something that'll probably need to be resolved by commercial agreement... but, in the meeting I mentioned that I think we can at least detect and flag the situation if it arises. A bold statement, and I should probably elaborate! In "draft-jenkins-cdni-metadata" (which has now expired), uCDN advertises a "SiteFeed". This is the full set of hostnames of uCDN content that dCDN can serve. Each hostname is linked to metadata describing the content. For DNS-based request routing, the hostname dCDN sees in the request from the user-agent will be the hostname that appears in uCDN's site feed (the whole problem is that hostname can't be manipulated as the request is routed by each CDN). So, if there are two uCDNs advertising the same site, its hostname will appear in both of their site feeds. If that happens, there's not a definite clash - for example, two uCDNs may advertise "example.com" but one may have content in "/movies" and the other in "/music". By examining the metadata though, if there is overlap in the patterns advertised, the ambiguity can be spotted by dCDN. Once dCDN sees the potential conflict it can do whatever's appropriate under its interconnect agreements - probably reject or ignore that piece of metadata from one of the uCDNs, perhaps log that it's doing so, perhaps notify the uCDN, perhaps flag the issue to its own operators. (At present it sounds like the "SiteFeed" concept from "draft-jenkins-cdni-metadata" will survive the merge with "draft-caulfield-cdni-metadata-core", probably as something called a "host index".) Rob. From ben@niven-jenkins.co.uk Wed Apr 4 15:58:15 2012 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 25D6611E812B for ; Wed, 4 Apr 2012 15:58:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHZHrrP8IftK for ; Wed, 4 Apr 2012 15:58:13 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4799311E812C for ; Wed, 4 Apr 2012 15:58:13 -0700 (PDT) Received: from [67.201.75.9] (helo=[10.71.3.48]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SFZ9W-0008Ix-KF; Wed, 04 Apr 2012 23:58:12 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Wed, 4 Apr 2012 23:58:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rob Murray X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Triggers interface 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, 04 Apr 2012 22:58:15 -0000 Rob, Kevin, On 4 Apr 2012, at 22:46, Rob Murray wrote: > Hi Kevin, >=20 > Apologies for the delayed response, and thank you for clarifying that = use > case. >=20 > I'd be interested to hear from others, but my initial thinking is that > triggered activity is most likely to be pushed into the network quite > quickly, and happen in parallel with other triggers. So, unless dCDN > decides it's overloaded, each trigger will probably not spend much = time in > "pending" state. If that's the case, offering the appearance of > finer-grained control over the scheduling may not add much. But, that > said, a priority indication would be an easy thing to add to the = protocol > (now or later), if it's thought to be useful. Ordering triggers is one thing, having priorities is another. What does priority mean in the context of a trigger (i.e. what is it = prioritised against)? - Priority against other triggers from the same user? - Priority from other triggers from the same uCDN (which might have been = created by different services/users of that uCDN)? - Priority against triggers from a different uCDN? I think it quickly becomes a non-straightforward problem to scope and = define the semantics necessary for interoperability and I'm far from = convinced we need to go there (I've never worked with a CDN that allows = their equivalent of triggers to be prioritised but I haven't worked with = them all). My view is the ordering within a trigger request should be sufficient = for our needs and let's avoid the can of worms that would be priorities = for triggers until we are certain we actually need that added = complexity. Ben >=20 > The subject of trigger ordering was discussed further in Paris, = outside > the WG session. In particular - Matt Caulfield pointed out that in a > cascade of CDNs, careful ordering of request initiation by uCDN into = dCDN > could be lost when dCDN passes the triggers downstream. >=20 > I think we concluded that a trigger request should be allowed to = contain > an ordered list of triggers. Failure of any one of the triggers will = be > reported as failure of the whole request, and dCDN must pass on = ordered > triggers to its dCDNs as ordered triggers. Internally however, each = CDN > may still process those triggers in parallel, so the new semantics of > content invalidate/purge up to the time the request was received still > apply. Under this scheme, to replace some content, you'd bundle an > invalidate/purge with a preposition in a single request. That = eliminates > the window where newly acquired content could be invalidated/purged. >=20 > I'll update the draft to reflect that, and the other comments = received. >=20 > Many thanks, > Rob. >=20 > On 28/03/2012 15:40, "Kevin J Ma" wrote: >=20 >> Hi Rob, >>=20 >> Wrt priorities, I was thinking about a case where there are a large >> number >> of trigger requests, possibly initiated by end customers, e.g., the = uCDN >> provides a web portal to allow customers to purge/invalidate content. >> Not >> all customers/administrators are created equal, and not wanting to >> delete, >> remember, and repost every trigger, it might be useful to have >> priorities. >> I agree that we may not want triggers to be pre-emptive, and the dCDN >> may >> have its own priorities, but if a uCDN and dCDN negotiate some >> understanding, >> outside the scope of CDNI, would a priority field be useful? >>=20 >> thanx. >>=20 >> -- Kevin J. Ma >>=20 >>> -----Original Message----- >>> From: Rob Murray [mailto:RMurray@velocix.com] >>> Sent: Wednesday, March 28, 2012 6:25 AM >>> To: Kevin J Ma; Kent Leung (kleung); cdni@ietf.org >>> Subject: Re: [CDNi] CDNI Triggers interface >>>=20 >>> Hi Kevin, and thanks - responses inline... >>>=20 >>> On 28/03/2012 02:08, "Kevin J Ma" wrote: >>>=20 >>>> Hi Rob, >>>>=20 >>>> I think the doc does a good job of clearly defining the space. >>>> I had a couple of questions: >>>>=20 >>>> - Section 4.4 mentions returning 404/410 on subsequent requests for = a >>>> resource after deletion. I assume this also applies to section = 4.3 >>>> and explicit deletion? Might be worth clarifying in section 4.3? >>>=20 >>> Yes, will do. >>>=20 >>>> - Along the lines of Matt and Kent's questions about request >>> ordering, >>>> I was wondering about repeat requests. The current set of = triggers >>>> are fairly idemopotent, so perhaps it would only be an = optimization >>>> for them, but are there concerns for duplicate requests or = requests >>>> with overlapping urls/patterns wrt any pending or active = triggers? >>>=20 >>> I think the interaction we want to avoid is between invalidate/purge = and >>> preposition, I hope my suggestion for using trigger "ctime" to = indicate >>> which data should be invalidated/purged addresses that? And, as you = say, >>> the current operations are fairly idempotent. >>>=20 >>> Each uCDN can only affect its own data, so it should be in full = control >>> of >>> any interactions. If it asks dCDN to do something silly with = overlapping >>> URLs/paterns, I don't think dCDN should try to second-guess it. >>>=20 >>>> - For trigger creation, would it make sense to have a priority = field, >>>> to allow uCDNs to influence the order in which dCDNs process >>> triggers? >>>=20 >>> Whether it's possible to influence the order of processing will = depend a >>> lot on the implementation in dCDN. It may or may not be possible to >>> stop/pause/pace triggered activity on any given cache, or across the >>> network. Allowing the uCDN to set a priority might give an illusion = of >>> control that it doesn't have. >>>=20 >>> Do you have a particular use-case in mind? One that springs to mind >>> would >>> be that uCDN has made a time-consuming request, then wants to inject >>> something more urgent. In this case it has the option of deleting = the >>> original trigger (dCDN may or may not stop work on it) and = re-creating >>> it >>> later, the idempotence of the operations helps us again there. >>>=20 >>> Overall, I think it's probably best to keep things simple and leave >>> scheduling/ordering of triggers under uCDN control by expecting it = to >>> make >>> requests and wait for completions in an order it likes. >>>=20 >>>=20 >>>> thanx. >>>>=20 >>>> -- Kevin J. Ma >>>>=20 >>>>> -----Original Message----- >>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On = Behalf >>> Of >>>>> Rob Murray >>>>> Sent: Sunday, March 25, 2012 7:43 AM >>>>> To: Kent Leung (kleung); cdni@ietf.org >>>>> Subject: Re: [CDNi] CDNI Triggers interface >>>>>=20 >>>>> Thanks Kent - replies inline ... >>>>>=20 >>>>> On 22/03/2012 18:11, "Kent Leung (kleung)" = wrote: >>>>>=20 >>>>>> Hi Rob. Nice write-up. Here are some comments on the draft. >>>>>>=20 >>>>>> 1. Sect. 2: Nit for "The trigger may request action on either >>> metadata >>>>>> or on content". Reword to "The trigger may request action on = either >>>>>> metadata or content"? >>>>>=20 >>>>> Will do. >>>>>=20 >>>>>> 2. Sect. 2: Any thoughts on the scalability aspect of using = RESTful >>> web >>>>>> service assuming there will be many dCDNs providing delivery = service >>>>> for >>>>>> a uCDN? These triggers will likely apply on all the dCDNs. >>>>>=20 >>>>> Since uCDN has the contract with the Content Owner (or with = another >>> uCDN >>>>> that does), it has ultimate responsibility for ensuring that = triggers >>>>> are >>>>> acted upon - I think it will need to track which dCDNs have its = data >>> and >>>>> which have completed its triggers, for auditing purposes if = nothing >>>>> else? >>>>> Because it's got that responsibility, uCDN will want a way to >>>>> interrogate >>>>> dCDN for status of triggers so, correspondingly, dCDN will need to >>> track >>>>> and report state of triggers. >>>>>=20 >>>>> So, I'd say per-trigger, per-interconnect state will exist at both >>> ends >>>>> of the interface whether it's RESTful or not. Does that answer the >>>>> concern? I can add some descriptive text to the draft along those >>> lines >>>>> if >>>>> it does. >>>>>=20 >>>>> Do you have a feel for the numbers of interconnects a given CDN is >>>>> likely >>>>> to have? I can't find an indication in the problem-statement or >>>>> requirements - but I'd imagine each CDN will have a relatively = small >>>>> number >>>>> of interconnect agreements, perhaps up to low tens? Generally I'd >>> think >>>>> CDNs will have many fewer interconnects than Delivery Surrogates, = but >>> an >>>>> exception might be a "broker" CDN that owns content but doesn't do >>> the >>>>> actual delivery itself. In that case, I'd guess we're not talking >>> about >>>>> thousands of interconnects but perhaps it might get into hundreds? = I >>>>> don't have any actual facts or data to cloud my thinking though = (!), >>> so >>>>> I'd be interested to hear other views. >>>>>=20 >>>>>> 3. Sect. 4: Typo in "For example, is anticipated that decisions = on >>> use >>>>>> of HTTPS for other CDNI interfaces will be adopted for Triggers." >>>>>=20 >>>>> Will fix. >>>>>=20 >>>>>> 4. Sect. 4.1: The Trigger Request must be processed in the = sequence >>> as >>>>>> triggered by the uCDN? Is there a message sequencing method = defined? >>>>> For >>>>>> example, uCDN wants to purge a specific content, then preposition >>> that >>>>>> content. What happens when the message arrives at dCDN out of = order? >>>>>=20 >>>>> Good point, thanks, I've not covered that. >>>>>=20 >>>>> If we define the invalidate/purge triggers to mean "invalidate or >>> purge >>>>> data obtained before this trigger was created" (before "ctime" of = the >>>>> Trigger Status Resource), I think that solves the problem. For >>> example, >>>>> a >>>>> use-case for "invalidate" followed by "preposition" would be an >>>>> emergency >>>>> fix to some metadata or content - with this change, by issuing >>> triggers >>>>> in >>>>> order after the data is repaired, uCDN can be sure incorrect data = is >>>>> deleted. But, data acquired from the same location after the = repair >>>>> (either as a result of pre-positioning or normal operation) will = not >>>>> need >>>>> to be re-fetched. The invalidate/purge and the preposition = triggers >>> can >>>>> run concurrently. >>>>>=20 >>>>> I makes the semantics of invalidate/purge cleaner anyway. If >>> (repaired) >>>>> data can still obtained from affected URL, it'd be hard for uCDN = to >>>>> guarantee that when a purge completes no data from affected URLs >>> exists >>>>> in dCDN. Much easier for it to say that data acquired before a = given >>>>> time has been invalidated/purged from the network. >>>>>=20 >>>>>> 5. Sect. 4.2: Nit for ".. to cheaply check for change .." Maybe " = .. >>> to >>>>>> inherently check for change .."? >>>>>=20 >>>>> How about "... to check for change in status of a resource or >>> collection >>>>> of resources without re-fetching the whole resource or = collection." >>>>>=20 >>>>>>=20 >>>>>> 6. Sect 4.2: Reword " to indicate the frequency it would like = uCDN >>> to >>>>>> poll at." to " to indicate the frequency of polling by the uCDN"? >>>>>=20 >>>>> How about "The dCDN should use the cache control headers for >>> responses >>>>> to >>>>> GETs for Trigger Status Resources and Collections to indicate the >>>>> frequency at which it recommends uCDN should poll for change." >>>>>=20 >>>>>> Kent >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On = Behalf >>> Of >>>>>> Rob Murray >>>>>> Sent: Wednesday, February 29, 2012 1:25 PM >>>>>> To: cdni@ietf.org >>>>>> Subject: [CDNi] CDNI Triggers interface >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> I've just uploaded a new draft that proposes a CDNI Triggers >>> interface >>>>>> ... >>>>>>=20 >>>>>> http://datatracker.ietf.org/doc/draft-murray-cdni-triggers/ >>>>>>=20 >>>>>>=20 >>>>>> There was some discussion at the last WG meeting about whether >>> triggers >>>>>> fit best as part of the control or metadata interface - the >>> suggestion >>>>>> was >>>>>> that concrete proposals for the interface might help us spot >>>>> commonality >>>>>> with one or the other, so let's see! >>>>>>=20 >>>>>> Please take a look, your comments are welcome. >>>>>>=20 >>>>>> Best regards, >>>>>> Rob. >>>>>>=20 >>>>>>=20 >>>>>> On 29/02/2012 19:37, "internet-drafts@ietf.org" >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>> A new version of I-D, draft-murray-cdni-triggers-00.txt has been >>>>>>> successfully submitted by Rob Murray and posted to the IETF >>>>> repository. >>>>>>>=20 >>>>>>> Filename: draft-murray-cdni-triggers >>>>>>> Revision: 00 >>>>>>> Title: CDN Interconnect Triggers >>>>>>> Creation date: 2012-02-29 >>>>>>> WG ID: Individual Submission >>>>>>> Number of pages: 33 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> This document proposes a mechanism for a CDN to trigger = activity >>> in >>>>>>> an interconnected CDN that is configured to deliver content on >>> its >>>>>>> behalf. The upstream CDN can use this mechanism to request = that >>>>> the >>>>>>> downstream CDN pre-positions metadata or content, or that it = re- >>>>>>> validate or purge metadata or content. The upstream CDN can >>>>> monitor >>>>>>> the status of activity that it has triggered in the downstream >>> CDN. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF Secretariat >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From gilles.bertrand@orange.com Thu Apr 5 01:11:09 2012 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 A701921F87EE for ; Thu, 5 Apr 2012 01:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykHrmMoQuj+h for ; Thu, 5 Apr 2012 01:11:05 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1E60D21F87ED for ; Thu, 5 Apr 2012 01:10:59 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B60D05D8A17; Thu, 5 Apr 2012 10:10:58 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9E9645D8A16; Thu, 5 Apr 2012 10:10:58 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 10:10:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD1303.A153BB60" Date: Thu, 5 Apr 2012 10:10:45 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF0346E9E3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4F7604D9.90309@skytide.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 Thread-Index: Ac0OqKUl8XHUxpGwScCaY55ZddateAEWiIpQ References: <7A2D6D1F6AC99243A77D32820D8ABBC20E6F6587@xmb-sjc-235.amer.cisco.com><7A2D6D1F6AC99243A77D32820D8ABBC20E6F6B89@xmb-sjc-235.amer.cisco.com><291CC3F9E50E7641901A54E85D0977C65260911CB7@MAILR002.mail.lan><4F75FC84.2030600@skytide.com><291CC3F9E50E7641901A54E85D0977C65260911EC7@MAILR002.mail.lan> <4F7604D9.90309@skytide.com> From: To: , X-OriginalArrivalTime: 05 Apr 2012 08:10:58.0649 (UTC) FILETIME=[A1F2DC90:01CD1303] Cc: cdni@ietf.org, mvittal@cisco.com Subject: Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 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, 05 Apr 2012 08:11:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD1303.A153BB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roy, =20 Thanks for bringing this useful discussion to the list. We have started = to tackle these points and to describe the Logging Framework in = http://tools.ietf.org/html/draft-bertrand-cdni-logging-00. Right now we = are extending it to propose transactions for the Logging format = negotiation and the Logging delivery. =20 Cheers, =20 Gilles =20 De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de = Roy Peterkofsky Envoy=E9 : vendredi 30 mars 2012 21:09 =C0 : Kevin J Ma Cc : cdni@ietf.org; Viveganandhan Mahesh Objet : Re: [CDNi] Comments on draft-lefaucheur-cdni-logging-delivery-00 =20 I think that getting into the mechanics of how a dCDN would capture data = about transactions it delivers is not central to the development of = interfaces to other CDNs, as long as the interface standards don't = demand anything that is infeasible. I think the point you are getting = to maybe refers to the steps involved in transferring rather than = capturing the log data? For example a true pull-oriented query = interface would actually require all participating dCDNs to store the = log data for at least some standardized retention time so that it would = be available for uCDNs to pull out. Another option would be that uCDNs = could send messages to dCDNs -- in advance of actual delivery = transactions -- specifying what data (and in what form) the uCDN wants = to receive about ensuing transactions. That messaging could include = conditional branches such as IF you are ABR-aware then send me data as = follows but IF NOT then send me data in this other way. The upshot of the above would be that the standards to be produced would = include: 1) what data elements and levels of aggregation should a dCDN be = required to make available to uCDNs, in both ABR-aware and = non-ABR-aware circumstances 2) if a dCDN chooses to make additional data elements and/or levels of = aggregation available, above and beyond the requirements, how should = they communicate this availability to uCDNs 3) what would be the means and format by which uCDNs transmit their = specification of desired data to dCDNs, including both the required = elements and any optional elements 4) what (if any) is the default logging/reporting to be provided by = dCDNs in the absence of such communication from uCDNs 5) what should be the format of the logs/reports sent by dCDNs in = response to the communciation sent by the uCDNs about their desired data = elements/levels of aggregation Working in that framework would allow most if not all of the issues that = have been brought up to be addressed=20 On 3/30/2012 11:51 AM, Kevin J Ma wrote:=20 Hi Roy, =20 > The discussion of possibly allowing the uCDN to specify (via > metadata transfer or other means) which log fields or formats it > wishes to receive actually, I feel, calls for stepping back and > reviewing whether we should have purely a logging interface or more > of a reporting or query interface=20 =20 Regardless of how the data is retrieved (push or pull), the dCDN needs to know whether or not it needs to extract the data. It may be that the dCDN does not automatically extract the X-foo header, and the metadata specifies that the X-foo header is desired. I think that would be needed even if it was a query interface? =20 -- Kevin J. Ma =20 From: Roy Peterkofsky [mailto:roy@skytide.com]=20 Sent: Friday, March 30, 2012 2:34 PM To: Kevin J Ma Cc: Francois Le Faucheur; Kent Leung (kleung); Niven-Jenkins Ben; = cdni@ietf.org; Viveganandhan Mahesh Subject: Re: [CDNi] Comments on = draft-lefaucheur-cdni-logging-delivery-00 =20 It sounds like there is clearly a need to have standards for logging = that cover two different scenarios: 1) Where the dCDN is ABR-aware and can produce session-level logs 2) Where the dCDN is not ABR-aware and can only produce = transaction-level (event- or fragment-level) logs I believe that the second scenario is required while the first is more = optional/nice-to-have. It would certainly be better to have it than not = although I think it would be by far the less common situation. The discussion of possibly allowing the uCDN to specify (via metadata = transfer or other means) which log fields or formats it wishes to = receive actually, I feel, calls for stepping back and reviewing whether = we should have purely a logging interface or more of a reporting or = query interface. That would, I imagine, allow the uCDN to specify: 1) what transactions do I want data about (specified by date range and = possibly other filter criteria) 2) what attributes and measures do I want to receive in my data 3) what level of aggregation do I want the data at (including for = example, at the session level or individual file level) On 3/30/2012 2:24 AM, Kevin J Ma wrote:=20 Hi Francois, =20 Wrt a flexible set of log fields, I think that it is a great idea, and it would be great if we could use metadata to specify log formats for specific content items or sets of content items. It is useful for = both content-specific logging (e.g., ABR), as well as client-specific = logging (e.g., X-* headers). For the W3C format, a separate log file for each format could result in a lot of files? Would aggregation cover that? =20 thanx. =20 -- Kevin J. Ma =20 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur Sent: Tuesday, March 13, 2012 2:39 PM To: Kent Leung (kleung); Niven-Jenkins Ben Cc: cdni@ietf.org; Viveganandhan Mahesh Subject: Re: [CDNi] Comments on = draft-lefaucheur-cdni-logging-delivery-00 =20 Ben, Kent, =20 Trying to extract the key points from the thread: =20 1) level of requirement for support of HTTP Adaptive Streaming Logging Session (ie ABR-aware logs): This is a valid question. The I-D proposes that some form of ABR-aware logging be mandatory. The rationale is that ABR is expected to be a very common delivery format = and requires some form of log compression over very voluminous per-segment logging. (BTW the I-D currently proposes that both Segment-Based = Logging format and Event-Based Logging format be mandatory. But come to think = of it, having only Event-Based Logging format mandatory would be = sufficient from my viewpoint). Ben argues that ABR-aware logging should not be mandatory as it = requires extra awareness. To get more input, I'd propose we move that requirement level = discussion to the cdni-requirements document, and have the logging I-D only talks about what such logs would look like. =20 =20 2) flexible set of log fields: I agree it is a good idea to allow the uCDN to customize the set of log fields reported by a dCDN for delivery. I was thinking that we'd start with defining a few "fixed" set of fields and then later add the customization, but perhaps we can start directly with customizable sets = of fields. To do that, I'd propose to: * retain the notion of Format Types (e.g Delivery_HTTP, Delivery_Adaptive_Event, ...) * define a set of candidate fields in each Format Type * have uCDN signal in Metadata interface the desired Format Type + set of fields needed (ie a subset of the set of candidate fields) * have dCDN explicitly indicate inside each log file (eg in File Header), the Format Type and the set of fields actually included * define handling of potential capability mismatch situations if any (eg1 uCDN requests a field that is not supported by dCDN if we allow = that, eg2 dCDN requests a format type that is not supported by dCDN). =20 =20 3) encoding format: I also agree the W3C extended log format is a good base candidate to = look at. =20 =20 4) summarization of Logging info for Adaptive Streaming delivery I believe some form of summarization is required. The Event-Based = Logging seems like a nice sweet-spot because it achieves a high summarization = gain without losing any info (ie any change in bandwidth/quality is logged). The I-D suggests we may be able to come up with another interesting = sweet- spot (Summary-Based Log) providing a huge summarization gain at the = cost of losing some details, but does not yet specify this. Ben, it'd be interesting to provide a brief write-up on the = summarization approach you mention so we can evaluate it (an email to the list woudl = be just fine). =20 =20 Thanks for the discussion. =20 Francois =20 =20 On 9 Mar 2012, at 00:48, Kent Leung (kleung) wrote: =20 Comments below. =20 =20 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of =20 Some comments on draft-lefaucheur-cdni-logging-delivery-00. =20 1) In section 3.2.1.2 (Segment-Based Log fields) and section 3.2.2.1 (Event Based Log Triggers) you mandate support for a number of log fields such as abr-protocol, representation, manifest-id and content-id that a downstream CDN may have no ability to generate, for example because the downstream CDN is acting in a pure HTTP reverse proxy = mode and may not be aware of that level of information and/or because the control of how to identify those fields is owned by the CSP and none of CDNs may have visibility of that mapping information. =20 Such a requirement to force CDNs and CDNI in general to require such mappings seems overkill to me. =20 KL> As stated, "... such aggregation requires a degree of application awareness in dCDN to recognize that the many HTTP requests correspond to a single video." So the premise is that the dCDN knows that it's delivering ABR content. In some cases, it's possible that the representation may not be known. =20 And my point is that I don't think that premise holds true and reality is the opposite, i.e. in general the dCDN will not know what it's delivering and only some dCDNs will have the application awareness to produce the log fields you suggest. =20 KL> Hmm, if the dCDN is not aware about the ABR session, then Section 3.2 would not apply since the dCDN considers itself to be delivering non-ABR content. Non-ABR content delivery does not require the log fields specified in this section. =20 =20 But in general, the log fields contain information that are pertinent to an ABR content. =20 I am not exactly sure what you mean by this. I agree the fields you suggest would be useful but I don't think having the application awareness to generate them should be a mandatory requirement for interoperability as suggested by section 3.2 =20 An implementation of the CDNI Logging interface MUST support logging for delivery of content using HTTP adaptive streaming in the = Segment- Based Logging format and the Event-Based Logging format, and MAY support logging in the Summary-Based Logging format. =20 KL> Are these fields in Sect 3.2 useful or applicable for non-ABR content delivery? No. I sense that I'm still missing your point. =20 =20 2) In section 6 you propose an additional requirement to allow an upstream CDN to indicate through CDNI metadata the log format the downstream CDN should use. Rather than define a set of specific formats, we could allow the upstream CDN to specify CDNI metadata indicating the specific log fields it is interested in receiving. The upstream CDN could then tailor what it asks for according to what it requires and avoid the transfer of log fields that it does not need. =20 KL> Agree that it's useful for uCDN to request only the information that's needed without extraneous fields. This can be accomplished = with a customized log format provided by uCDN. In a sense, this is a = superset of selective fields. =20 That is another approach which would probably make life easier for the dCDN. =20 4) If the motivation for summary/aggregated log lines is a concern over the volume of data that needs to be transferred then in Velocix we have done some experiments on using an alternative lookup table based structure for log lines that retains all the verbosity of the = original delivery log lines but by itself appears to give equivalent compression to gzip and combined with gzip reduces the size significantly when compared to what gzip alone achieves (in some cases averaging as little as 13 bits per complete log line). =20 If the volume of logs to be transferred is a concern and there is interest in investigating this approach further I can write-up more details either in a separate draft or as a section in draft-lefaucheur-cdni-logging-delivery. =20 KL> I think the intent is to summarize succinctly the ABR session in the logging. =20 I think they're two separate things. If we're worried about the volume of data our experiments show that can be significantly reduced using structured log files with lookup tables. That technique is applicable regardless of the actual fields in a log file. =20 Whether we require ABR session summary information to be logged is a separate discussion to how we might optimise the structure of any log files we require. =20 Ben =20 KL> Sure, I think we can discuss more on this when Francois is = available as I'm not clear on his thoughts. =20 Kent =20 I haven't discussed this in finer details with Francois yet. It seems to me that the compression technique can be considered as optimization in delivery of either session-based or event-based logging. We can discuss this further if our goals are aligned. =20 Kent =20 Ben _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni =20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni =20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni =20 =20 --=20 Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success = =20 =20 --=20 Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success = =20 ------_=_NextPart_001_01CD1303.A153BB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Roy,

 

Thanks for bringing this useful discussion to the list. We have = started to tackle these points and to describe the Logging Framework in = http:/= /tools.ietf.org/html/draft-bertrand-cdni-logging-00. Right now we = are extending it to propose transactions for the Logging format = negotiation and the Logging delivery.

 

Cheers,

 

Gilles

 

De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Roy Peterkofsky
Envoy=E9 : vendredi 30 mars 2012 = 21:09
=C0 : Kevin J Ma
Cc : cdni@ietf.org; = Viveganandhan Mahesh
Objet : Re: [CDNi] Comments on = draft-lefaucheur-cdni-logging-delivery-00

 

I think = that getting into the mechanics of how a dCDN would capture data about = transactions it delivers is not central to the development of interfaces = to other CDNs, as long as the interface standards don't demand anything = that is infeasible.  I think the point you are getting to maybe = refers to the steps involved in transferring rather than capturing the = log data?  For example a true pull-oriented query interface would = actually require all participating dCDNs to store the log data for at = least some standardized retention time so that it would be available for = uCDNs to pull out.  Another option would be that uCDNs could send = messages to dCDNs -- in advance of actual delivery transactions -- = specifying what data (and in what form) the uCDN wants to receive about = ensuing transactions.  That messaging could include conditional = branches such as IF you are ABR-aware then send me data as follows but = IF NOT then send me data in this other way.

The upshot of the = above would be that the standards to be produced would = include:

1) what data elements and levels of aggregation should a = dCDN be required to make available  to uCDNs, in both ABR-aware and = non-ABR-aware circumstances
2) if a dCDN chooses to make additional = data elements and/or levels of aggregation available, above and beyond = the requirements, how should they communicate this availability to = uCDNs
3) what would be the means and format by which uCDNs transmit = their specification of desired data to dCDNs, including both the = required elements and any optional elements
4) what (if any) is the = default logging/reporting to be provided by dCDNs in the absence of such = communication from uCDNs
5) what should be the format of the = logs/reports sent by dCDNs in response to the communciation sent by the = uCDNs about their desired data elements/levels of = aggregation

Working in that framework would allow most if not all = of the issues that have been brought up to be addressed

On = 3/30/2012 11:51 AM, Kevin J Ma wrote:

Hi Roy,

 

> The discussion of possibly allowing = the uCDN to specify (via

> metadata transfer or other means) which = log fields or formats it

> wishes to receive actually, I feel, = calls for stepping back and

> reviewing whether we should have = purely a logging interface or more

> of a reporting or query interface =

 

Regardless of how the data is retrieved = (push or pull), the dCDN

needs to know whether or not it needs to = extract the data.  It may

be that the dCDN does not automatically = extract the X-foo header,

and the metadata specifies that the = X-foo header is desired.  I

think that would be needed even if it = was a query interface?

 

--  Kevin J. = Ma

 

From: Roy Peterkofsky [mailto:roy@skytide.com] =
Sent: Friday, March 30, 2012 2:34 PM
To: Kevin J = Ma
Cc: Francois Le Faucheur; Kent Leung (kleung); = Niven-Jenkins Ben; cdni@ietf.org; = Viveganandhan Mahesh
Subject: Re: [CDNi] Comments on = draft-lefaucheur-cdni-logging-delivery-00

 

It = sounds like there is clearly a need to have standards for logging that = cover two different scenarios:

1) Where the dCDN is ABR-aware and = can produce session-level logs
2) Where the dCDN is not ABR-aware and = can only produce transaction-level (event- or fragment-level) = logs

I believe that the second scenario is required while the = first is more optional/nice-to-have.  It would certainly be better = to have it than not although I think it would be by far the less common = situation.

The discussion of possibly allowing the uCDN to = specify (via metadata transfer or other means) which log fields or = formats it wishes to receive actually, I feel, calls for stepping back = and reviewing whether we should have purely a logging interface or more = of a reporting or query interface.  That would, I imagine, allow = the uCDN to specify:

1) what transactions do I want data about = (specified by date range and possibly other filter criteria)
2) what = attributes and measures do I want to receive in my data
3) what level = of aggregation do I want the data at (including for example, at the = session level or individual file level)

On 3/30/2012 2:24 AM, = Kevin J Ma wrote: 

Hi =
Francois,
 
  Wrt a =
flexible set of log fields, I think that it is a great idea, =
and
  it would be great if we could use =
metadata to specify log formats for
  specific =
content items or sets of content items.  It is useful for =
both
  content-specific logging (e.g., ABR), =
as well as client-specific logging
  (e.g., =
X-* headers).  For the W3C format, a separate log file for =
each
  format could result in a lot of =
files?  Would aggregation cover =
that?
 
thanx.<=
/pre>
 
--  Kevin J. =
Ma
 
-----Original =
Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] =
On Behalf Of
Francois Le =
Faucheur
Sent: Tuesday, March 13, 2012 2:39 =
PM
To: Kent Leung (kleung); Niven-Jenkins =
Ben
Cc: cdni@ietf.org; Viveganandhan =
Mahesh
Subject: Re: [CDNi] Comments on =
draft-lefaucheur-cdni-logging-delivery-00
 
Ben, =
Kent,
 
Trying to extract =
the key points from the =
thread:
 
1) level of =
requirement for support of HTTP Adaptive Streaming =
Logging
Session (ie ABR-aware =
logs):
This is a valid =
question.
The I-D proposes that some form of =
ABR-aware logging be mandatory. The
rationale is =
that ABR is expected to be a very common delivery format =
and
requires some form of log compression over very =
voluminous per-segment
logging. (BTW the I-D =
currently proposes that both Segment-Based =
Logging
format and Event-Based Logging format be =
mandatory. But come to think of
it, having only =
Event-Based Logging format mandatory would be =
sufficient
from my =
viewpoint).
Ben argues that ABR-aware logging =
should not be mandatory as it requires
extra =
awareness.
To get more input, I'd propose we move =
that requirement level discussion
to the =
cdni-requirements document, and have the logging I-D only =
talks
about what such logs would look =
like.
 
 <=
/pre>
2) flexible set of log fields:
I agree it =
is a good idea to allow the uCDN to customize the set of =
log
fields reported by a dCDN for delivery. I was =
thinking that we'd start
with defining a few =
"fixed" set of fields and then later add =
the
customization, but perhaps we can start =
directly with customizable sets =
of
fields.
To do that, I'd =
propose to:
 * retain the notion of Format Types =
(e.g Delivery_HTTP,
Delivery_Adaptive_Event, =
...)
 * define a set of candidate fields in each =
Format Type
 * have uCDN signal in Metadata =
interface the desired Format Type +
set of fields =
needed (ie a subset of the set of candidate =
fields)
 * have dCDN explicitly indicate inside =
each log file (eg in File
Header), the Format Type =
and the set of fields actually included
 * define =
handling of potential capability mismatch situations if =
any
(eg1 uCDN requests a field that is not =
supported by dCDN if we allow that,
eg2 dCDN =
requests a format type that is not supported by =
dCDN).
 
 =

3) encoding format:
I also agree the W3C =
extended log format is a good base candidate to =
look
at.
 
 
4) summarization of Logging info for =
Adaptive Streaming delivery
I believe some form of =
summarization is required. The Event-Based =
Logging
seems like a nice sweet-spot because it =
achieves a high summarization gain
without losing =
any info (ie any change in bandwidth/quality is =
logged).
The I-D suggests we may be able to come up =
with another interesting sweet-
spot (Summary-Based =
Log) providing a huge summarization gain at the =
cost
of losing some details, but does not yet =
specify this.
Ben, it'd be interesting to provide a =
brief write-up on the summarization
approach you =
mention so we can evaluate it (an email to the list woudl =
be
just =
fine).
 
 =

Thanks for the =
discussion.
 
Francois
 
 
On 9 Mar 2012, at 00:48, Kent Leung (kleung) =
wrote:
 
Comments =
below.
 
 
-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] =
On =
Behalf
Of
 
Some comments on =
draft-lefaucheur-cdni-logging-delivery-00.
 
1) In section 3.2.1.2 (Segment-Based Log fields) and =
section 3.2.2.1
(Event Based Log Triggers) you =
mandate support for a number of log
fields such as =
abr-protocol, representation, manifest-id =
and
content-id
that a =
downstream CDN may have no ability to generate, for =
example
because the downstream CDN is acting in a =
pure HTTP reverse proxy mode
and may not be aware =
of that level of information and/or because =
the
control of how to identify those fields is =
owned by the CSP and =
none
of
CDNs may have =
visibility of that mapping =
information.
 
Such a =
requirement to force CDNs and CDNI in general to require =
such
mappings seems overkill to =
me.
 
KL> As stated, =
"... such aggregation requires a degree of =
application
awareness in dCDN to recognize that the =
many HTTP requests =
correspond
to
a single =
video." So the premise is that the dCDN knows that =
it's
delivering ABR content. In some cases, it's =
possible that the
representation may not be =
known.
 
And =
my point is that I don't think that premise holds true and =
reality
is the opposite, i.e. in general the dCDN =
will not know what it's
delivering and only some =
dCDNs will have the application awareness =
to
produce the log fields you =
suggest.
 
KL> Hmm, if =
the dCDN is not aware about the ABR session, then =
Section
3.2 would not apply since the dCDN =
considers itself to be delivering
non-ABR =
content.  Non-ABR content delivery does not require the =
log
fields specified in this =
section.
 
 
But in general, the =
log fields contain
information that are pertinent =
to an ABR =
content.
 
I =
am not exactly sure what you mean by this. I agree the fields =
you
suggest would be useful but I don't think =
having the application
awareness to generate them =
should be a mandatory requirement =
for
interoperability as suggested by section =
3.2
 
  An =
implementation of the CDNI Logging interface MUST support =
logging
  for delivery of content using HTTP =
adaptive streaming in the Segment-
  Based =
Logging format and the Event-Based Logging format, and =
MAY
  support logging in the Summary-Based =
Logging format.
 
KL> =
Are these fields in Sect 3.2 useful or applicable for =
non-ABR
content delivery? No. I sense that I'm =
still missing your =
point.
 
 =

2) =
In section 6 you propose an additional requirement to allow =
an
upstream CDN to indicate through CDNI metadata =
the log format the
downstream CDN should use. =
Rather than define a set of =
specific
formats,
we could =
allow the upstream CDN to specify CDNI metadata =
indicating
the
specific log =
fields it is interested in receiving. The upstream =
CDN
could then tailor what it asks for according to =
what it requires and
avoid the transfer of log =
fields that it does not =
need.
 
KL> Agree that =
it's useful for uCDN to request only the =
information
that's needed without extraneous =
fields. This can be accomplished =
with
a
customized log =
format provided by uCDN. In a sense, this is a =
superset
of selective =
fields.
 
Tha=
t is another approach which would probably make life easier for =
the
dCDN.
 
4) If =
the motivation for summary/aggregated log lines is a =
concern
over
the volume of data =
that needs to be transferred then in Velocix =
we
have
done some =
experiments on using an alternative lookup table =
based
structure for log lines that retains all the =
verbosity of the original
delivery log lines but by =
itself appears to give =
equivalent
compression
=

to gzip =
and combined with gzip reduces the size significantly =
when
compared to what gzip alone achieves (in some =
cases averaging =
as
little
as 13 bits per =
complete log line).
 
If =
the volume of logs to be transferred is a concern and there =
is
interest in investigating this approach further =
I can write-up more
details either in a separate =
draft or as a section =
in
draft-lefaucheur-cdni-logging-delivery.
 
KL> I think the intent is to =
summarize succinctly the ABR session =
in
the
logging.
 
I think they're two =
separate things. If we're worried about the =
volume
of data our experiments show that can be =
significantly reduced using
structured log files =
with lookup tables. That technique is =
applicable
regardless of the actual fields in a log =
file.
 
Whether we =
require ABR session summary information to be logged is =
a
separate discussion to how we might optimise the =
structure of any log
files we =
require.
 
Ben<=
/pre>
 
KL> Sure, I think we can =
discuss more on this when Francois is available
as =
I'm not clear on his =
thoughts.
 
Kent
 
I haven't discussed =
this in finer details with Francois yet. It
seems =
to me that the compression technique can be considered =
as
optimization in delivery of either session-based =
or =
event-based
logging.
We can =
discuss this further if our goals are =
aligned.
 
Kent=

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

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

CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/=
mailman/listinfo/cdni
_____________=
__________________________________
CDNi mailing =
list
CDNi@ietf.org
https://www.ietf.org/=
mailman/listinfo/cdni
 
 
-- 
Roy Peterkofsky
Vice President, Product =
Management
Skytide -- the leader in Digital Media Performance =
Management
www.skytide.com
(510) =
250-4284

Read our new white paper: The 4 Keys to Telco CDN Success

 

--
Roy Peterkofsky
Vice President, Product = Management
Skytide -- the leader in Digital Media Performance = Management
www.skytide.com
(510) = 250-4284

Read our new white paper: The 4 Keys to Telco CDN = Success

------_=_NextPart_001_01CD1303.A153BB60-- From flefauch@cisco.com Tue Apr 10 10:30:00 2012 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 24DE111E80E8 for ; Tue, 10 Apr 2012 10:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.244 X-Spam-Level: X-Spam-Status: No, score=-10.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTg6uCHzFxEA for ; Tue, 10 Apr 2012 10:29:59 -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 C4B1B11E80F4 for ; Tue, 10 Apr 2012 10:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=424; q=dns/txt; s=iport; t=1334078998; x=1335288598; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=KN8kf252p2ZBQ/UYqNiepdZTblbA3NuU0YeynDKdQNk=; b=TrQOj6QmLQhBvlXgaGN0Kx2BJAXL4eIxyn7VYFsoGNLXnO2gQXVaWcbx YG1+3Pw/+xjnXEL3KTHPCUd/M3m6YlL11TBKPD9VL5lUnMZLDP70GVqGt gbIwjG5GrYLTsByW9dB60Tge64UQfkIC9hrw7Gu5pe/XTD8WSTJEGBKhi 0=; X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="70507955" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 10 Apr 2012 17:29:55 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3AHTsbG027752; Tue, 10 Apr 2012 17:29:55 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Apr 2012 19:30:00 +0200 Message-Id: <7CBD48B5-DEF1-447E-A2DB-239793CEE209@cisco.com> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] Draft CDNI minutes of IETF-83 meeting posted. 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, 10 Apr 2012 17:30:00 -0000 Folks, Draft minutes have been posted at = http://www.ietf.org/proceedings/83/minutes/minutes-83-cdni.txt. Please send us comments/corrections as needed. Thanks again to Gilles Bertrand for taking notes during the sessions. Note that the audio recording is available for the Thu session (and has = been used to enhance the minutes) but is not yet available for the Fri = session. Cheers Francois & Rich= From flefauch@cisco.com Fri Apr 13 05:58:24 2012 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 9162021F8621 for ; Fri, 13 Apr 2012 05:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.362 X-Spam-Level: X-Spam-Status: No, score=-10.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D6U46dbtPsQ for ; Fri, 13 Apr 2012 05:58:24 -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 B19BF21F85D9 for ; Fri, 13 Apr 2012 05:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=744; q=dns/txt; s=iport; t=1334321903; x=1335531503; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=Pyi+YCxxusJUys8EM+PdFoLMjsz4dkTsTPmx3MENfVI=; b=P2yeM+w4N8FYTdrCSLApWB1NVpX9pbbhfXfd38ZjfmB5P3v8z09MjMpd c63Z0yvcFNl7bAcrz6JXOcQ5sbi32dyu0kOVRKp6Pix5CbVrKUUFw55PI aXBbsUrHUQqbd4o0OvfAQ2/VnSIycEB1vi3dZjZRFAd86EjzzaaUBUH+w A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAP8hiE+Q/khR/2dsb2JhbABFtzCBB4IiASeCGRmHbAuYJ4EooA2OM4JBYwSVbI5NgWmCaQ X-IronPort-AV: E=Sophos;i="4.75,417,1330905600"; d="scan'208";a="135074486" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 13 Apr 2012 12:58:22 +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 q3DCwM1I027459 for ; Fri, 13 Apr 2012 12:58:22 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Apr 2012 14:58:34 +0200 Message-Id: <5339DEEB-766C-4523-B352-52BC07FA24F3@cisco.com> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] CDNI Virtual Interim Meetings on May 29 & 30, 2012 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, 13 Apr 2012 12:58:24 -0000 Hello, As discussed in Paris, the CDNI working group will hold: * a (3-hour) virtual interim meeting on "HTTP Adaptive = Streaming" on Tuesday May 29, 2012 Draft agenda, times and remote attendance details are = accessible from: = http://www.ietf.org/proceedings/interim/2012/05/29/cdni/agenda/agenda-inte= rim-2012-cdni-1.html * a (3-hour) virtual interim meeting on "Footprint & = Capabilities Advertisement" on Wednesday May 30, 2012 Draft agenda, times and remote attendance details are = accessible from: = http://www.ietf.org/proceedings/interim/2012/05/30/cdni/agenda/agenda-inte= rim-2012-cdni-2.html Please take note of these timeslots. Looking forward to your participation. Francois & Rich= From flefauch@cisco.com Wed Apr 18 05:27:26 2012 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 88D2E21F84A7 for ; Wed, 18 Apr 2012 05:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.457 X-Spam-Level: X-Spam-Status: No, score=-10.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdWiUTuMKT9W for ; Wed, 18 Apr 2012 05:27:22 -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 287F821F853F for ; Wed, 18 Apr 2012 05:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=2815; q=dns/txt; s=iport; t=1334752041; x=1335961641; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=+ttObJ2emkYeYDfDMynsyZ5XNLM64SUMpqN5a+6JuHY=; b=Gtv4T9bY1yaWBvqEm2/GslM2GBPBVUjsl0fwcYtmILyPkQl3ceBZkLHN ZMT4ZnuHuHK8g/RQofbDRHz8gFcy60G8UgFMyTrQQteT3GoBL0AIYCW/K Srev43fD/h0X5oxP4XbOKddRm5ZCXb2sHTIQlkozpNt+Ez7qtAEDbgkH9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAL6yjk+Q/khR/2dsb2JhbABEsT2BB4IiAWaBc4dtmV6gJo1DgkJjBJVvhXOIXoFpgmk X-IronPort-AV: E=Sophos;i="4.75,441,1330905600"; d="scan'208";a="135526502" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 18 Apr 2012 12:27:18 +0000 Received: from [144.254.53.106] ([144.254.53.106]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3ICRItq016386; Wed, 18 Apr 2012 12:27:18 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Apr 2012 14:27:37 +0200 Message-Id: <4223D895-FF04-457E-9ED2-A259AB29B520@cisco.com> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] Charter adjustement: milestones related to the Request Routing Interface 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, 18 Apr 2012 12:27:26 -0000 Folks, As you know, what we had initially identified as one CDNI interface (the = Request Routing Interface) actually comprises two different components, = with different requirements, that will likely be realized by leveraging = different base protocols (e.g. web-services/HTTP/DNS for one, e.g. = BGP/ALTO for the other) and that will be progressed at different pace. = These two components are: * "Request Routing Interface/Redirection": to support the = synchronous operation of actually redirecting a user request. * "Request Routing Interface/Footprint & Capabilities = Advertisement": to support the asynchronous advertisement of footprint = and capabilities by a dCDN that allows a uCDN to decide whether to = redirect particular user requests to that dCDN. The working-group chairs and ADs propose to bring the charter in = alignment with that, and specifically to adjust the list of milestones = of the CDN charter.=20 The proposed change is: OLD: " Dec 2012 - Submit specification of the CDNI Request Routing interface = to IESG as Proposed Standard " NEW: " Dec 2012 - Submit specification of the CDNI Request = Routing/Redirection interface to IESG as Proposed Standard Jun 2013 - Submit specification of the CDNI Request Routing/Footprint = & Capabilities Advertisement interface to IESG as Proposed Standard " Please let us know if you have any objections, concerns or comments on = this proposed charter adjustment. Thank you Francois & Rich = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D A little more optional background, just in case: Here is some text straight from the CDNI framework document about the = two components of the Request Routing Interface: " We may think of the request routing interface as comprising two parts: 1.the asynchronous advertisement of footprint and capabilities by a dCDN = that allows a uCDN to decide whether to redirect particular user = requests to that dCDN; and 2. the synchronous operation of actually redirecting a user request. (These are somewhat analogous to the operations of routing and = forwarding in IP.) =94 " Here is the definition of the Request Routing Interface as per current = charter. I believe that definition still stands as is and need not be = modified since it is broad enough to encompass the two components: " * A specification of the "CDNI request-routing interface". This interface will allow an upstream CDN request routing system to = obtain from the downstream CDN the information necessary to perform request redirection. " From ietf-ipr@ietf.org Tue Apr 24 12:27:21 2012 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 6772021E80B9; Tue, 24 Apr 2012 12:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+nWAsPaTC0b; Tue, 24 Apr 2012 12:27:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D441921E8013; Tue, 24 Apr 2012 12:27:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: gilles.bertrand@orange.com, grant.watson@bt.com, kevin.ma@azukisystems.com, philip.eardley@bt.com, emile.stephan@orange.com, trevor.burbridge@bt.com X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120424192720.8796.23818.idtracker@ietfa.amsl.com> Date: Tue, 24 Apr 2012 12:27:20 -0700 X-Mailman-Approved-At: Wed, 25 Apr 2012 08:25:39 -0700 Cc: cdni@ietf.org, ipr-announce@ietf.org Subject: [CDNi] IPR Disclosure: Azuki Systems, Inc.'s Statement about IPR related to draft-ietf-cdni-use-cases-04 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 Apr 2012 19:27:21 -0000 Dear Gilles Bertrand, Grant Watson, Kevin Ma, Philip Eardley, Stephan Emile= , Trevor Burbridge: An IPR disclosure that pertains to your Internet-Draft entitled "Use Cases= for Content Delivery Network Interconnection" (draft-ietf-cdni-use-cases) was submitted to the IETF Secretariat on 2012-04-24 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1764/). The title of the IPR disclosure is "Azuki Systems, Inc.'s Statement about IPR related to draft-ietf-cdni-use- cases-04.""); The IETF Secretariat From flefauch@cisco.com Wed Apr 25 09:45:51 2012 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 B08F021F85AE for ; Wed, 25 Apr 2012 09:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.515 X-Spam-Level: X-Spam-Status: No, score=-8.515 tagged_above=-999 required=5 tests=[AWL=-1.516, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6doGwox2BdR for ; Wed, 25 Apr 2012 09:45:49 -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 4F8B521F86A8 for ; Wed, 25 Apr 2012 09:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=14120; q=dns/txt; s=iport; t=1335372343; x=1336581943; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=kGr+Fir5PRQ5nonB9/c6BQlvbikP8YPpAjJZiFwmVaQ=; b=WW4pd1yXaT/Aw+/DL/UEs8v8RqbiYPcKAdiNFWMRIC6rm9bNCPGGgLnf ScSeeUW7ARmibpvUudViwogiUq+FMQRQ9yGAy8Sp8/7uChxRC6epDdXpP 3qo+rRuNmBgeB1PxnOpOoyhcjZVbH1XW8M55x3p4SwOCeWCr20BIIamqm M=; X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="136219240" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 25 Apr 2012 16:45:42 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3PGjfEs022521; Wed, 25 Apr 2012 16:45:41 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Apr 2012 18:45:38 +0200 Message-Id: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> To: draft-ietf-cdni-use-cases@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: cdni@ietf.org Subject: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases 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 Apr 2012 16:45:52 -0000 To use-cases authors, Below are my shepherd review comments of cdni-uses-cases. I think the document is in a good shape and captures well the key = targeted use cases. I identified two remaining significant points to be addressed, and also = have included many suggestions to improve the document. I suggest we resolve the two significant points on the list and leave it = to editor/authors to decide how to dispose of the suggestions for = improvement offline. Cheers Francois Significant points =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D *** section 8 security considerations I have a few specific issues with the current text of the Security = Considerations section. But I don't really see the need to have an = expanded Security Considerations section in both the use-case document = and the problem-statement (particularly considering that the first IESG = review comments on problem-statement suggest expanding the security = considerations section there), in particular because the security = considerations currently brought up in use-cases are not specific to = individual use cases bur rather generic to the whole CDN interconnection = problem space. So my proposal would be to remove the whole discussion from use-cases = (i.e. the first 4 paragraphs) and refer to the Security Considerations = section of the Problem Statement e.g.. by replacing: "=20 This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze these threats in detail. " with: " This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze the associated threats. Those are = discussed in [I-D.ietf-cdni-problem-statement]. " ***section A.1: I still have a problem with the text of that section. I thought we had converged on an agreement that the text would: * explain that CSPs may take into account very = multiple/arbitrary/specific criteria in their policy * explain that the CDNs are only expected to enforce a few = specific policy rules (e.g. geo-blocking, time window) and for = enforcement of all fancy CSP policy we propose that the responsibilities = be divided into (1) the CSP being responsible for the fancy policy = decision and (ii) the CDN for merely enforcing the CSP decision without = having to understand the policy (e.g. via URI signing). Do we not agree on that or not? The current text says that CDN selection and surrogate selection "are = influenced by these policies" (referring to the fancy CSP policies). I = do not agree with that. I don;t think we want CDN Selection or Surrogate = selection to be influenced by whether a movie shoudl be available 14 or = 28 days after DVD release, or whether a given resolution is "too high" = for a particular user or terminal.=20 Also, the paragraph keeps talking about "dCDN selection or Surrogate = selection" may fail for some fancy policy reasons. I don't understand = what it means to "fail" , but more importantly again, I don't think we = want CDN request routing decisions to be factoring very fancy CSP policy = rules. Do we agree or not? The last paragraphs gives examples of the CSP objectives of supporting = delivery policies in CDNs, and those are fine and can be achieved with = the set of mechanisms discussed above (i.e. goeblocking + time window + = URI signing). Suggestions for improvements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ***Abstract replace "CDNI" by "CDN Interconnection". *** section 1: expand the first instance of CDNI into "CDN Interconnection (CDNI)". *** section 1: "Then, the document highlights the need for interoperability to exchange and enforce content delivery policies (Section 5)." I'd suggest replacing "for interoperability to exchange" by "for = interoperability to allow exchange" or by "for interoperability in order = to exchange" *** section 1.1: Do you feel that the two additional terms are really specific to the = use-case document (in which case their definition should stay in this = document) or are they likely useful in other documents (in which case = their definition should be migrated to the framework document)? Personally, I would say that those terms might be useful in other = documents/discussions (eg I am pretty sure we'd need to refer to the = "Delivering CDN" in other context). *** section 1.1: "Access CDN: A CDN that is directly connected to the End User's access." I think this definition needs to be a little more specific. "Directly = connected" does not mean "L2 connectivity" (because an on-net cache = maybe a few L2 hops away), nor does it mean "L3 connectivity" (because = an OTT CDN cache has IP connectivity to an enduser). I think you mean = something in between, more or less that the CDN and the access are = within the same IP administrative domain, or something close to that. = Can you try refine that definition? *** section 1.3: " o improve the experience for the End User; for instance delivery has lower latency (decreased round-trip-time between the user and the delivery server) and better robustness," To be more comprehensive in justifying the claims, how about: " o improve the experience for the End User; for instance delivery has lower latency (decreased round-trip-time and higher throughput = between the user and the delivery server) and better robustness (ability to use multiple = delivery servers)," *** section 1.3: "o reduce the Content Service Provider's (CSP) costs, such as datacenter capacity, space, and electricity consumption, as popular content is delivered through the CDN rather than through the CSP's servers." The current wording raises the question of "if it reduces the costs by = reducing expenses in the CSP datacenter, why does it not correspondingly = increase the cost by increasing expenses in the CDN (which the CDN = provider then charges back to the CSP)?" I think the gain is in the scale and effective pooling of CDN resources = across many CSPs. Could you refine the wording to explain why there is = indeed a net gain? *** section 1.3: Replace: " An example is depicted in Figure 1. Two CDN Providers establish a CDN = Interconnection. " with: " An example is depicted in Figure 1 where two CDN Providers establish a = CDN Interconnection. " (this is to minimize the redundancy with the sentence coming below: "CDN = Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.") *** section 1.3: replace: " "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs." with: "Independently, CDN Provider 'A' and CDN Provider 'B' agree to = interconnect their CDNs." this is to clarify that the A<->B agreement is not specific to the 1<->A = agreement *** section 1.3: replace: " When a User Agent requests content from CSP-1, CDN-A considers that = delivery by CDN-B is appropriate " with: " When a given User Agent requests content from CSP-1, CDN-A may consider = that delivery by CDN-B is appropriate " *** section 1.3: replace: " CDN-A has delegated the handling of requests for CSP-1's content through = the CDN Interconnection agreement, thus, the content is actually = delivered from CDN-B. " with: " Through the CDN Interconnection arrangements put in place between CDN-A = and CDN-B (as a result of the CDN Interconnection agreement established = between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the = request to CDN-B and the content is actually delivered to the User Agent = by CDN-B. " (the current wording suggests that all deliveries of CSP1 content would = be handled by CDN-B, which is typically not the case i.e. only a subset = of the requests are redirected thy CDN-A to CDN-B)=20 *** section 1.3: replace: " CSP-1 benefits because it only needs to make one business agreement and = one physical connection, with CDN Provider 'A' " with: " CSP-1 benefits because it only needs to make one business agreement and = one technical arrangement with CDN Provider 'A' " (this is because the interfacing between CSP and uCDN comprises more = than "physical connection"). *** section 1.3: replace: " CSP-1 had also gone to the trouble of making a business agreement with = CDN Provider 'B' " with: " CSP-1 had also gone to the trouble of making a business agreement and = technical arrangemement with CDN Provider 'B' " *** section 1.3: replace: " But it does not want " with: " However, CSP-2 may not want " *** section 2.1: after=20 " o without incurring additional transit and other network costs that would result from serving content from geographically or topologically remote Surrogates. " add: " o without incurring the cost of deploying and operating Surrogates and = the associated CDN infrastructure that may not be justified in the = corresponding geographic region (e.g. because of relatively low delivery = volume, or conversely because of the high investments that would be = needed to satisfy the high volume) " *** section 2.2: replace: " A large CDN Provider may also operate CDNs from several subsidiaries = (which may rely on different CDN technologies, see Section 4.2). In = certain circumstances, the CDN Provider needs to make its CDNs = interoperate to provide a consistent service to its customers on its = whole footprint. " with: " A large CDN Provider may have several subsidiaries that also each = operate their own CDN (which may rely on different CDN technologies, see = Section 4.2). In certain circumstances, the CDN Provider needs to make = these CDNs interoperate to provide a consistent service to its customers = on the whole collective footprint.=20 " *** section 2.3: replace: " injected into the access network " with: " injected into the ISP network " *** section 2.3: replace: " There are mutual benefits to the Access CDN, " with: " There are mutual benefits to the ISP (acting as an Access CDN), " *** section 2.3: replace: " for example, QoS and reduced round trip time. " with: " for example, reduced content startup time or increased video quality and = resolution of adaptive streaming content. " (I don't think RTT is very meaningful to a CSP customer) *** section 2.4: The nomadic user is currently defined as "moving between CDNs" which is = sort of a self-serving definition to justify CDN interconnection. I = think we should rather define the nomadic user as "moving between access = networks" and then justify that leveraging local CDNs can bring a lot of = benefits. This requires the following text edits: s/who move between CDNs/who move between access networks/ s/moving between different CDN Providers/moving between different access = networks/ *** section 2.4: replace: " which may reside " with: " which may be located " *** section 2.4:" I propose to remove the sentence: " The term "Nomadic" does not necessarily relate to geographic roaming. " because this point has already been fully (and better) clarified in the = preceding paragraph. *** section 2.4: replace: " the WiFi or mobile provider " with: " the WiFi or mobile provider (NSP B) " *** section 3.1: replace: " needs CDN capacities " with: " needs CDN capacity " *** section 3.2.1: The text mentions two options (use OS, use another CDN). I think the = section shoudl probably also mention the most obvious option (i.e. use = other surrogates in the same CDN). Or alternatively, clarify that the = considered situation is where there is a partial failure of some = surrogates resulting in the remaining surrogates being fully loaded. *** section 3.2.1: replace: " to both distribute load between origin servers and attempt content = acquisition from alternate origin servers when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other origin server options, " with: " to both distribute load between content sources and attempt content = acquisition from alternate content sources when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other content source options, " (I believe everywhere else we use "origin server" to refer to the OS of = the CSP and "content source" as the generic term for getting content = including origin server and uCDN) *** section 3.2.2: replace: " the selection of content acquisition sources should be considered. " with: " the selection of content acquisition sources should be considered and = facilitated. " (i.e. it is not just a matter of "thinking" about it: it must be = explicitly allowed or at leads made easier). *** section 4.1: "to serve a proportion of its traffic that requires HTTPS." can you include a reference for HTTPS? *** section 5: replace: " An important aspect of the above use cases " with: " An important aspect common to all the above use cases " *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line = 618, but no explicit reference was found in the text I'd suggest you add an explicit reference. For example, in "1. = Introduction" you could replace: " The document can be used to guide the definition of the requirements to = be supported by the various CDNI interfaces defined in = [I-D.ietf-cdni-problem-statement]. " by " The document can be used to guide the definition of the requirements (as = documented in [I-D.ietf-cdni-requirements]) to be supported by the set = of CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. " (BTW, independely of the reference issue, "the set of CDNI interfaces" = might read better than "the various CDNI interfaces"). *** The document has a disclaimer for pre-RFC5378 work, but was first = submitted on or after 10 November 2008. Does it really need the = disclaimer?= From ben@niven-jenkins.co.uk Wed Apr 25 10:39:03 2012 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 58CF821F8846 for ; Wed, 25 Apr 2012 10:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.799 X-Spam-Level: X-Spam-Status: No, score=-104.799 tagged_above=-999 required=5 tests=[AWL=-5.800, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3KwMMGezwkK for ; Wed, 25 Apr 2012 10:39:02 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2513621F883D for ; Wed, 25 Apr 2012 10:39:01 -0700 (PDT) Received: from [81.134.152.4] (helo=xxx.corp.velocix.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SN6B9-0003hm-JK; Wed, 25 Apr 2012 18:39:00 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> Date: Wed, 25 Apr 2012 18:38:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6596CC9C-13AE-4CAB-96DF-5BD50B7CDC9F@niven-jenkins.co.uk> References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: draft-ietf-cdni-use-cases@tools.ietf.org, cdni@ietf.org Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases 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 Apr 2012 17:39:03 -0000 Francois, On 25 Apr 2012, at 17:45, Francois Le Faucheur wrote: > I identified two remaining significant points to be addressed, and = also have included many suggestions to improve the document. > I suggest we resolve the two significant points on the list and leave = it to editor/authors to decide how to dispose of the suggestions for = improvement offline. >=20 > Cheers >=20 > Francois >=20 >=20 > Significant points > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > *** section 8 security considerations > I have a few specific issues with the current text of the Security = Considerations section. But I don't really see the need to have an = expanded Security Considerations section in both the use-case document = and the problem-statement (particularly considering that the first IESG = review comments on problem-statement suggest expanding the security = considerations section there), in particular because the security = considerations currently brought up in use-cases are not specific to = individual use cases bur rather generic to the whole CDN interconnection = problem space. > So my proposal would be to remove the whole discussion from use-cases = (i.e. the first 4 paragraphs) and refer to the Security Considerations = section of the Problem Statement e.g.. by replacing: > "=20 > This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze these threats in detail. > " > with: > " > This document focuses on the motivational use cases for CDN = Interconnection, and does not analyze the associated threats. Those are = discussed in [I-D.ietf-cdni-problem-statement]. > " Works for me. As part of reworking the Security Considerations section = in the problem statement I will see what text from the use cases draft = can be reused. > ***section A.1: > I still have a problem with the text of that section. > I thought we had converged on an agreement that the text would: > * explain that CSPs may take into account very = multiple/arbitrary/specific criteria in their policy > * explain that the CDNs are only expected to enforce a few = specific policy rules (e.g. geo-blocking, time window) and for = enforcement of all fancy CSP policy we propose that the responsibilities = be divided into (1) the CSP being responsible for the fancy policy = decision and (ii) the CDN for merely enforcing the CSP decision without = having to understand the policy (e.g. via URI signing). > Do we not agree on that or not? I agree with what you said, i.e. CSPs handle fancy policy and then grant = tokens/whatever that the dCDN can validate to ensure they are only = delivering to End Users the CSP has granted access too. CDN policies should not be CSP specific - they should just cover things = like geo-blocking rules etc. Ben >=20 > The current text says that CDN selection and surrogate selection "are = influenced by these policies" (referring to the fancy CSP policies). I = do not agree with that. I don;t think we want CDN Selection or Surrogate = selection to be influenced by whether a movie shoudl be available 14 or = 28 days after DVD release, or whether a given resolution is "too high" = for a particular user or terminal.=20 >=20 > Also, the paragraph keeps talking about "dCDN selection or Surrogate = selection" may fail for some fancy policy reasons. I don't understand = what it means to "fail" , but more importantly again, I don't think we = want CDN request routing decisions to be factoring very fancy CSP policy = rules. > Do we agree or not? >=20 > The last paragraphs gives examples of the CSP objectives of supporting = delivery policies in CDNs, and those are fine and can be achieved with = the set of mechanisms discussed above (i.e. goeblocking + time window + = URI signing). >=20 >=20 > Suggestions for improvements > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > ***Abstract > replace "CDNI" by "CDN Interconnection". >=20 > *** section 1: > expand the first instance of CDNI into "CDN Interconnection (CDNI)". >=20 > *** section 1: > "Then, the document highlights the need for interoperability to > exchange and enforce content delivery policies (Section 5)." > I'd suggest replacing "for interoperability to exchange" by "for = interoperability to allow exchange" or by "for interoperability in order = to exchange" >=20 > *** section 1.1: > Do you feel that the two additional terms are really specific to the = use-case document (in which case their definition should stay in this = document) or are they likely useful in other documents (in which case = their definition should be migrated to the framework document)? > Personally, I would say that those terms might be useful in other = documents/discussions (eg I am pretty sure we'd need to refer to the = "Delivering CDN" in other context). >=20 > *** section 1.1: > "Access CDN: > A CDN that is directly connected to the End User's access." > I think this definition needs to be a little more specific. "Directly = connected" does not mean "L2 connectivity" (because an on-net cache = maybe a few L2 hops away), nor does it mean "L3 connectivity" (because = an OTT CDN cache has IP connectivity to an enduser). I think you mean = something in between, more or less that the CDN and the access are = within the same IP administrative domain, or something close to that. = Can you try refine that definition? >=20 > *** section 1.3: > " o improve the experience for the End User; for instance delivery = has > lower latency (decreased round-trip-time between the user and the > delivery server) and better robustness," > To be more comprehensive in justifying the claims, how about: > " o improve the experience for the End User; for instance delivery = has > lower latency (decreased round-trip-time and higher throughput = between the user and the > delivery server) and better robustness (ability to use multiple = delivery servers)," >=20 > *** section 1.3: > "o reduce the Content Service Provider's (CSP) costs, such as > datacenter capacity, space, and electricity consumption, as > popular content is delivered through the CDN rather than through > the CSP's servers." > The current wording raises the question of "if it reduces the costs by = reducing expenses in the CSP datacenter, why does it not correspondingly = increase the cost by increasing expenses in the CDN (which the CDN = provider then charges back to the CSP)?" > I think the gain is in the scale and effective pooling of CDN = resources across many CSPs. Could you refine the wording to explain why = there is indeed a net gain? >=20 > *** section 1.3: > Replace: > " > An example is depicted in Figure 1. Two CDN Providers establish a CDN = Interconnection. > " > with: > " > An example is depicted in Figure 1 where two CDN Providers establish a = CDN Interconnection. > " > (this is to minimize the redundancy with the sentence coming below: = "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs.") >=20 >=20 > *** section 1.3: > replace: > " > "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their = CDNs." > with: > "Independently, CDN Provider 'A' and CDN Provider 'B' agree to = interconnect their CDNs." > this is to clarify that the A<->B agreement is not specific to the = 1<->A agreement >=20 >=20 > *** section 1.3: > replace: > " > When a User Agent requests content from CSP-1, CDN-A considers that = delivery by CDN-B is appropriate > " > with: > " > When a given User Agent requests content from CSP-1, CDN-A may = consider that delivery by CDN-B is appropriate > " >=20 >=20 > *** section 1.3: > replace: > " > CDN-A has delegated the handling of requests for CSP-1's content = through the CDN Interconnection agreement, thus, the content is actually = delivered from CDN-B. > " > with: > " > Through the CDN Interconnection arrangements put in place between = CDN-A and CDN-B (as a result of the CDN Interconnection agreement = established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can = redirect the request to CDN-B and the content is actually delivered to = the User Agent by CDN-B. > " > (the current wording suggests that all deliveries of CSP1 content = would be handled by CDN-B, which is typically not the case i.e. only a = subset of the requests are redirected thy CDN-A to CDN-B)=20 >=20 >=20 > *** section 1.3: > replace: > " > CSP-1 benefits because it only needs to make one business agreement = and one physical connection, with CDN Provider 'A' > " > with: > " > CSP-1 benefits because it only needs to make one business agreement = and one technical arrangement with CDN Provider 'A' > " > (this is because the interfacing between CSP and uCDN comprises more = than "physical connection"). >=20 >=20 > *** section 1.3: > replace: > " > CSP-1 had also gone to the trouble of making a business agreement with = CDN Provider 'B' > " > with: > " > CSP-1 had also gone to the trouble of making a business agreement and = technical arrangemement with CDN Provider 'B' > " >=20 > *** section 1.3: > replace: > " > But it does not want > " > with: > " > However, CSP-2 may not want > " >=20 > *** section 2.1: > after=20 > " > o without incurring additional transit and other network costs that > would result from serving content from geographically or > topologically remote Surrogates. > " > add: > " > o without incurring the cost of deploying and operating Surrogates and = the associated CDN infrastructure that may not be justified in the = corresponding geographic region (e.g. because of relatively low delivery = volume, or conversely because of the high investments that would be = needed to satisfy the high volume) > " >=20 >=20 > *** section 2.2: > replace: > " > A large CDN Provider may also operate CDNs from several subsidiaries = (which may rely on different CDN technologies, see Section 4.2). In = certain circumstances, the CDN Provider needs to make its CDNs = interoperate to provide a consistent service to its customers on its = whole footprint. > " > with: > " > A large CDN Provider may have several subsidiaries that also each = operate their own CDN (which may rely on different CDN technologies, see = Section 4.2). In certain circumstances, the CDN Provider needs to make = these CDNs interoperate to provide a consistent service to its customers = on the whole collective footprint.=20 > " >=20 >=20 > *** section 2.3: > replace: > " > injected into the access network > " > with: > " > injected into the ISP network > " >=20 > *** section 2.3: > replace: > " > There are mutual benefits to the Access CDN, > " > with: > " > There are mutual benefits to the ISP (acting as an Access CDN), > " >=20 >=20 > *** section 2.3: > replace: > " > for example, QoS and reduced round trip time. > " > with: > " > for example, reduced content startup time or increased video quality = and resolution of adaptive streaming content. > " > (I don't think RTT is very meaningful to a CSP customer) >=20 >=20 > *** section 2.4: > The nomadic user is currently defined as "moving between CDNs" which = is sort of a self-serving definition to justify CDN interconnection. I = think we should rather define the nomadic user as "moving between access = networks" and then justify that leveraging local CDNs can bring a lot of = benefits. > This requires the following text edits: > s/who move between CDNs/who move between access networks/ > s/moving between different CDN Providers/moving between different = access networks/ >=20 > *** section 2.4: > replace: > " > which may reside > " > with: > " > which may be located > " >=20 > *** section 2.4:" > I propose to remove the sentence: > " > The term "Nomadic" does not necessarily relate to geographic roaming. > " > because this point has already been fully (and better) clarified in = the preceding paragraph. >=20 >=20 >=20 > *** section 2.4: > replace: > " > the WiFi or mobile provider > " > with: > " > the WiFi or mobile provider (NSP B) > " >=20 >=20 > *** section 3.1: > replace: > " > needs CDN capacities > " > with: > " > needs CDN capacity > " >=20 > *** section 3.2.1: > The text mentions two options (use OS, use another CDN). I think the = section shoudl probably also mention the most obvious option (i.e. use = other surrogates in the same CDN). Or alternatively, clarify that the = considered situation is where there is a partial failure of some = surrogates resulting in the remaining surrogates being fully loaded. >=20 >=20 > *** section 3.2.1: > replace: > " > to both distribute load between origin servers and attempt content = acquisition from alternate origin servers when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other origin server options, > " > with: > " > to both distribute load between content sources and attempt content = acquisition from alternate content sources when acquisition failures = occur. When normal content acquisition fails, a CDN may need to try = other content source options, > " > (I believe everywhere else we use "origin server" to refer to the OS = of the CSP and "content source" as the generic term for getting content = including origin server and uCDN) >=20 > *** section 3.2.2: > replace: > " > the selection of content acquisition sources should be considered. > " > with: > " > the selection of content acquisition sources should be considered and = facilitated. > " > (i.e. it is not just a matter of "thinking" about it: it must be = explicitly allowed or at leads made easier). >=20 >=20 > *** section 4.1: > "to serve a proportion of its traffic that requires HTTPS." > can you include a reference for HTTPS? >=20 >=20 > *** section 5: > replace: > " > An important aspect of the above use cases > " > with: > " > An important aspect common to all the above use cases > " >=20 >=20 > *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line = 618, but no explicit reference was found in the text > I'd suggest you add an explicit reference. For example, in "1. = Introduction" you could replace: > " > The document can be used to guide the definition of the requirements = to be supported by the various CDNI interfaces defined in = [I-D.ietf-cdni-problem-statement]. > " > by > " > The document can be used to guide the definition of the requirements = (as documented in [I-D.ietf-cdni-requirements]) to be supported by the = set of CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. > " > (BTW, independely of the reference issue, "the set of CDNI interfaces" = might read better than "the various CDNI interfaces"). >=20 >=20 > *** The document has a disclaimer for pre-RFC5378 work, but was first = submitted on or after 10 November 2008. Does it really need the = disclaimer? > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Thu Apr 26 14:46:27 2012 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 9A68021E8039 for ; Thu, 26 Apr 2012 14:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XllboCYVFlRC for ; Thu, 26 Apr 2012 14:46:26 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id EC00821E803A for ; Thu, 26 Apr 2012 14:46:25 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A87E9416BB7; Thu, 26 Apr 2012 17:46:24 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7086F416E8F; Thu, 26 Apr 2012 17:46:21 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Thu, 26 Apr 2012 17:46:11 -0400 From: Kevin J Ma To: Francois Le Faucheur , "draft-ietf-cdni-use-cases@tools.ietf.org" Date: Thu, 26 Apr 2012 17:46:18 -0400 Thread-Topic: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases Thread-Index: Ac0jAuTaXNE6yAyfQGqz1o1rS/+PggA7n+vA Message-ID: <291CC3F9E50E7641901A54E85D0977C65260C10A37@MAILR002.mail.lan> References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> In-Reply-To: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases 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 Apr 2012 21:46:27 -0000 Hi Francois, > * explain that the CDNs are only expected to enforce a few specific > policy rules (e.g. geo-blocking, time window) and for enforcement of all > fancy CSP policy we propose that the responsibilities be divided into (1) > the CSP being responsible for the fancy policy decision and (ii) the CDN > for merely enforcing the CSP decision without having to understand the > policy (e.g. via URI signing). > Do we not agree on that or not? I agree that the CDN should enforce any policy that is defined in metadata. If a supported metadata dictates a restriction, regardless of any individua= l interpretation of the semantic fanciness, the restriction should be enforce= d. If a dCDN does not support a given metadata, it can express that to the uCD= N, which should influence the inter-CDN request routing. > Also, the paragraph keeps talking about "dCDN selection or Surrogate > selection" may fail for some fancy policy reasons. I don't understand wha= t > it means to "fail", but more importantly again, I don't think we want CDN > request routing decisions to be factoring very fancy CSP policy rules. > Do we agree or not? The failure could probably be a more generic delivery failure, due to restrictions defined in the metadata, though, the framework document shows the metadata checks as part of request routing decision making which presumably influences dCDN/Surrogate selection? The fanciness of the policy should not matter, as long as the metadata which conveys the enforcement of that policy is clear and succinct. The inter-CDN request routing should be aware of the capabilities of each dCDN and not delegate to dCDNs that lack support for capabilities which are deemed mandatory. The use cases do not dictate any specific implementations. They do not require request routing to implement fancy policy rules. A valid implementation could wrap all the fancy policy rules into a nice neat boolean value. An equally valid implementation could implement extra super fancy policy rules. The use case does not mandate one or the other. Is the concern that specific portions are not valid, or that the descriptio= ns are unclear, or is the concern about an assumed implementation's fanciness? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Francois Le Faucheur > Sent: Wednesday, April 25, 2012 12:46 PM > To: draft-ietf-cdni-use-cases@tools.ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases > > To use-cases authors, > > Below are my shepherd review comments of cdni-uses-cases. > > I think the document is in a good shape and captures well the key targete= d > use cases. > I identified two remaining significant points to be addressed, and also > have included many suggestions to improve the document. > I suggest we resolve the two significant points on the list and leave it > to editor/authors to decide how to dispose of the suggestions for > improvement offline. > > Cheers > > Francois > > > Significant points > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > *** section 8 security considerations > I have a few specific issues with the current text of the Security > Considerations section. But I don't really see the need to have an > expanded Security Considerations section in both the use-case document an= d > the problem-statement (particularly considering that the first IESG revie= w > comments on problem-statement suggest expanding the security > considerations section there), in particular because the security > considerations currently brought up in use-cases are not specific to > individual use cases bur rather generic to the whole CDN interconnection > problem space. > So my proposal would be to remove the whole discussion from use-cases > (i.e. the first 4 paragraphs) and refer to the Security Considerations > section of the Problem Statement e.g.. by replacing: > " > This document focuses on the motivational use cases for CDN > Interconnection, and does not analyze these threats in detail. > " > with: > " > This document focuses on the motivational use cases for CDN > Interconnection, and does not analyze the associated threats. Those are > discussed in [I-D.ietf-cdni-problem-statement]. > " > > > ***section A.1: > I still have a problem with the text of that section. > I thought we had converged on an agreement that the text would: > * explain that CSPs may take into account very > multiple/arbitrary/specific criteria in their policy > * explain that the CDNs are only expected to enforce a few specific > policy rules (e.g. geo-blocking, time window) and for enforcement of all > fancy CSP policy we propose that the responsibilities be divided into (1) > the CSP being responsible for the fancy policy decision and (ii) the CDN > for merely enforcing the CSP decision without having to understand the > policy (e.g. via URI signing). > Do we not agree on that or not? > > The current text says that CDN selection and surrogate selection "are > influenced by these policies" (referring to the fancy CSP policies). I do > not agree with that. I don;t think we want CDN Selection or Surrogate > selection to be influenced by whether a movie shoudl be available 14 or 2= 8 > days after DVD release, or whether a given resolution is "too high" for a > particular user or terminal. > > Also, the paragraph keeps talking about "dCDN selection or Surrogate > selection" may fail for some fancy policy reasons. I don't understand wha= t > it means to "fail" , but more importantly again, I don't think we want CD= N > request routing decisions to be factoring very fancy CSP policy rules. > Do we agree or not? > > The last paragraphs gives examples of the CSP objectives of supporting > delivery policies in CDNs, and those are fine and can be achieved with th= e > set of mechanisms discussed above (i.e. goeblocking + time window + URI > signing). > > > Suggestions for improvements > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ***Abstract > replace "CDNI" by "CDN Interconnection". > > *** section 1: > expand the first instance of CDNI into "CDN Interconnection (CDNI)". > > *** section 1: > "Then, the document highlights the need for interoperability to > exchange and enforce content delivery policies (Section 5)." > I'd suggest replacing "for interoperability to exchange" by "for > interoperability to allow exchange" or by "for interoperability in order > to exchange" > > *** section 1.1: > Do you feel that the two additional terms are really specific to the use- > case document (in which case their definition should stay in this > document) or are they likely useful in other documents (in which case > their definition should be migrated to the framework document)? > Personally, I would say that those terms might be useful in other > documents/discussions (eg I am pretty sure we'd need to refer to the > "Delivering CDN" in other context). > > *** section 1.1: > "Access CDN: > A CDN that is directly connected to the End User's access." > I think this definition needs to be a little more specific. "Directly > connected" does not mean "L2 connectivity" (because an on-net cache maybe > a few L2 hops away), nor does it mean "L3 connectivity" (because an OTT > CDN cache has IP connectivity to an enduser). I think you mean something > in between, more or less that the CDN and the access are within the same > IP administrative domain, or something close to that. Can you try refine > that definition? > > *** section 1.3: > " o improve the experience for the End User; for instance delivery has > lower latency (decreased round-trip-time between the user and the > delivery server) and better robustness," > To be more comprehensive in justifying the claims, how about: > " o improve the experience for the End User; for instance delivery has > lower latency (decreased round-trip-time and higher throughput > between the user and the > delivery server) and better robustness (ability to use multiple > delivery servers)," > > *** section 1.3: > "o reduce the Content Service Provider's (CSP) costs, such as > datacenter capacity, space, and electricity consumption, as > popular content is delivered through the CDN rather than through > the CSP's servers." > The current wording raises the question of "if it reduces the costs by > reducing expenses in the CSP datacenter, why does it not correspondingly > increase the cost by increasing expenses in the CDN (which the CDN > provider then charges back to the CSP)?" > I think the gain is in the scale and effective pooling of CDN resources > across many CSPs. Could you refine the wording to explain why there is > indeed a net gain? > > *** section 1.3: > Replace: > " > An example is depicted in Figure 1. Two CDN Providers establish a CDN > Interconnection. > " > with: > " > An example is depicted in Figure 1 where two CDN Providers establish a CD= N > Interconnection. > " > (this is to minimize the redundancy with the sentence coming below: "CDN > Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.") > > > *** section 1.3: > replace: > " > "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs." > with: > "Independently, CDN Provider 'A' and CDN Provider 'B' agree to > interconnect their CDNs." > this is to clarify that the A<->B agreement is not specific to the 1<->A > agreement > > > *** section 1.3: > replace: > " > When a User Agent requests content from CSP-1, CDN-A considers that > delivery by CDN-B is appropriate > " > with: > " > When a given User Agent requests content from CSP-1, CDN-A may consider > that delivery by CDN-B is appropriate > " > > > *** section 1.3: > replace: > " > CDN-A has delegated the handling of requests for CSP-1's content through > the CDN Interconnection agreement, thus, the content is actually delivere= d > from CDN-B. > " > with: > " > Through the CDN Interconnection arrangements put in place between CDN-A > and CDN-B (as a result of the CDN Interconnection agreement established > between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the > request to CDN-B and the content is actually delivered to the User Agent > by CDN-B. > " > (the current wording suggests that all deliveries of CSP1 content would b= e > handled by CDN-B, which is typically not the case i.e. only a subset of > the requests are redirected thy CDN-A to CDN-B) > > > *** section 1.3: > replace: > " > CSP-1 benefits because it only needs to make one business agreement and > one physical connection, with CDN Provider 'A' > " > with: > " > CSP-1 benefits because it only needs to make one business agreement and > one technical arrangement with CDN Provider 'A' > " > (this is because the interfacing between CSP and uCDN comprises more than > "physical connection"). > > > *** section 1.3: > replace: > " > CSP-1 had also gone to the trouble of making a business agreement with CD= N > Provider 'B' > " > with: > " > CSP-1 had also gone to the trouble of making a business agreement and > technical arrangemement with CDN Provider 'B' > " > > *** section 1.3: > replace: > " > But it does not want > " > with: > " > However, CSP-2 may not want > " > > *** section 2.1: > after > " > o without incurring additional transit and other network costs that > would result from serving content from geographically or > topologically remote Surrogates. > " > add: > " > o without incurring the cost of deploying and operating Surrogates and th= e > associated CDN infrastructure that may not be justified in the > corresponding geographic region (e.g. because of relatively low delivery > volume, or conversely because of the high investments that would be neede= d > to satisfy the high volume) > " > > > *** section 2.2: > replace: > " > A large CDN Provider may also operate CDNs from several subsidiaries > (which may rely on different CDN technologies, see Section 4.2). In > certain circumstances, the CDN Provider needs to make its CDNs > interoperate to provide a consistent service to its customers on its whol= e > footprint. > " > with: > " > A large CDN Provider may have several subsidiaries that also each operate > their own CDN (which may rely on different CDN technologies, see Section > 4.2). In certain circumstances, the CDN Provider needs to make these CDNs > interoperate to provide a consistent service to its customers on the whol= e > collective footprint. > " > > > *** section 2.3: > replace: > " > injected into the access network > " > with: > " > injected into the ISP network > " > > *** section 2.3: > replace: > " > There are mutual benefits to the Access CDN, > " > with: > " > There are mutual benefits to the ISP (acting as an Access CDN), > " > > > *** section 2.3: > replace: > " > for example, QoS and reduced round trip time. > " > with: > " > for example, reduced content startup time or increased video quality and > resolution of adaptive streaming content. > " > (I don't think RTT is very meaningful to a CSP customer) > > > *** section 2.4: > The nomadic user is currently defined as "moving between CDNs" which is > sort of a self-serving definition to justify CDN interconnection. I think > we should rather define the nomadic user as "moving between access > networks" and then justify that leveraging local CDNs can bring a lot of > benefits. > This requires the following text edits: > s/who move between CDNs/who move between access networks/ > s/moving between different CDN Providers/moving between different access > networks/ > > *** section 2.4: > replace: > " > which may reside > " > with: > " > which may be located > " > > *** section 2.4:" > I propose to remove the sentence: > " > The term "Nomadic" does not necessarily relate to geographic roaming. > " > because this point has already been fully (and better) clarified in the > preceding paragraph. > > > > *** section 2.4: > replace: > " > the WiFi or mobile provider > " > with: > " > the WiFi or mobile provider (NSP B) > " > > > *** section 3.1: > replace: > " > needs CDN capacities > " > with: > " > needs CDN capacity > " > > *** section 3.2.1: > The text mentions two options (use OS, use another CDN). I think the > section shoudl probably also mention the most obvious option (i.e. use > other surrogates in the same CDN). Or alternatively, clarify that the > considered situation is where there is a partial failure of some > surrogates resulting in the remaining surrogates being fully loaded. > > > *** section 3.2.1: > replace: > " > to both distribute load between origin servers and attempt content > acquisition from alternate origin servers when acquisition failures occur= . > When normal content acquisition fails, a CDN may need to try other origin > server options, > " > with: > " > to both distribute load between content sources and attempt content > acquisition from alternate content sources when acquisition failures > occur. When normal content acquisition fails, a CDN may need to try othe= r > content source options, > " > (I believe everywhere else we use "origin server" to refer to the OS of > the CSP and "content source" as the generic term for getting content > including origin server and uCDN) > > *** section 3.2.2: > replace: > " > the selection of content acquisition sources should be considered. > " > with: > " > the selection of content acquisition sources should be considered and > facilitated. > " > (i.e. it is not just a matter of "thinking" about it: it must be > explicitly allowed or at leads made easier). > > > *** section 4.1: > "to serve a proportion of its traffic that requires HTTPS." > can you include a reference for HTTPS? > > > *** section 5: > replace: > " > An important aspect of the above use cases > " > with: > " > An important aspect common to all the above use cases > " > > > *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 618= , > but no explicit reference was found in the text > I'd suggest you add an explicit reference. For example, in "1. > Introduction" you could replace: > " > The document can be used to guide the definition of the requirements to b= e > supported by the various CDNI interfaces defined in [I-D.ietf-cdni- > problem-statement]. > " > by > " > The document can be used to guide the definition of the requirements (as > documented in [I-D.ietf-cdni-requirements]) to be supported by the set of > CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. > " > (BTW, independely of the reference issue, "the set of CDNI interfaces" > might read better than "the various CDNI interfaces"). > > > *** The document has a disclaimer for pre-RFC5378 work, but was first > submitted on or after 10 November 2008. Does it really need the > disclaimer? > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Thu Apr 26 14:46:49 2012 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 3DCE821E8039 for ; Thu, 26 Apr 2012 14:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_MUTUALBENEFIT=2, J_BACKHAIR_11=1, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-wmyR7zmit1 for ; Thu, 26 Apr 2012 14:46:47 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 84EB921F844F for ; Thu, 26 Apr 2012 14:46:44 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 11D2E5535E2; Thu, 26 Apr 2012 17:46:34 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5300A553FF1; Thu, 26 Apr 2012 17:46:27 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Thu, 26 Apr 2012 17:46:09 -0400 From: Kevin J Ma To: Ben Niven-Jenkins , Francois Le Faucheur Date: Thu, 26 Apr 2012 17:46:25 -0400 Thread-Topic: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases Thread-Index: Ac0jClJH67tJMHzmQkGWHDp9McKLTwA5rR7w Message-ID: <291CC3F9E50E7641901A54E85D0977C65260C10A38@MAILR002.mail.lan> References: <5388986F-034F-4E38-A5A3-78B6E30F56A5@cisco.com> <6596CC9C-13AE-4CAB-96DF-5BD50B7CDC9F@niven-jenkins.co.uk> In-Reply-To: <6596CC9C-13AE-4CAB-96DF-5BD50B7CDC9F@niven-jenkins.co.uk> 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: "draft-ietf-cdni-use-cases@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases 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 Apr 2012 21:46:49 -0000 Hi Ben, > I agree with what you said, i.e. CSPs handle fancy policy and then grant > tokens/whatever that the dCDN can validate to ensure they are only > delivering to End Users the CSP has granted access too. I do not disagree with your statement. I just will note that if the CSP is nolonger in control of which dCDN the request will ultimately be delegat= ed to, the "whatever" has to be enforced across all dCDNs. thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Ben Niven-Jenkins > Sent: Wednesday, April 25, 2012 1:39 PM > To: Francois Le Faucheur > Cc: draft-ietf-cdni-use-cases@tools.ietf.org; cdni@ietf.org > Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases > > Francois, > > On 25 Apr 2012, at 17:45, Francois Le Faucheur wrote: > > > I identified two remaining significant points to be addressed, and also > have included many suggestions to improve the document. > > I suggest we resolve the two significant points on the list and leave i= t > to editor/authors to decide how to dispose of the suggestions for > improvement offline. > > > > Cheers > > > > Francois > > > > > > Significant points > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > *** section 8 security considerations > > I have a few specific issues with the current text of the Security > Considerations section. But I don't really see the need to have an > expanded Security Considerations section in both the use-case document an= d > the problem-statement (particularly considering that the first IESG revie= w > comments on problem-statement suggest expanding the security > considerations section there), in particular because the security > considerations currently brought up in use-cases are not specific to > individual use cases bur rather generic to the whole CDN interconnection > problem space. > > So my proposal would be to remove the whole discussion from use-cases > (i.e. the first 4 paragraphs) and refer to the Security Considerations > section of the Problem Statement e.g.. by replacing: > > " > > This document focuses on the motivational use cases for CDN > Interconnection, and does not analyze these threats in detail. > > " > > with: > > " > > This document focuses on the motivational use cases for CDN > Interconnection, and does not analyze the associated threats. Those are > discussed in [I-D.ietf-cdni-problem-statement]. > > " > > Works for me. As part of reworking the Security Considerations section in > the problem statement I will see what text from the use cases draft can b= e > reused. > > > ***section A.1: > > I still have a problem with the text of that section. > > I thought we had converged on an agreement that the text would: > > * explain that CSPs may take into account very > multiple/arbitrary/specific criteria in their policy > > * explain that the CDNs are only expected to enforce a few specific > policy rules (e.g. geo-blocking, time window) and for enforcement of all > fancy CSP policy we propose that the responsibilities be divided into (1) > the CSP being responsible for the fancy policy decision and (ii) the CDN > for merely enforcing the CSP decision without having to understand the > policy (e.g. via URI signing). > > Do we not agree on that or not? > > I agree with what you said, i.e. CSPs handle fancy policy and then grant > tokens/whatever that the dCDN can validate to ensure they are only > delivering to End Users the CSP has granted access too. > > CDN policies should not be CSP specific - they should just cover things > like geo-blocking rules etc. > > Ben > > > > > The current text says that CDN selection and surrogate selection "are > influenced by these policies" (referring to the fancy CSP policies). I do > not agree with that. I don;t think we want CDN Selection or Surrogate > selection to be influenced by whether a movie shoudl be available 14 or 2= 8 > days after DVD release, or whether a given resolution is "too high" for a > particular user or terminal. > > > > Also, the paragraph keeps talking about "dCDN selection or Surrogate > selection" may fail for some fancy policy reasons. I don't understand wha= t > it means to "fail" , but more importantly again, I don't think we want CD= N > request routing decisions to be factoring very fancy CSP policy rules. > > Do we agree or not? > > > > The last paragraphs gives examples of the CSP objectives of supporting > delivery policies in CDNs, and those are fine and can be achieved with th= e > set of mechanisms discussed above (i.e. goeblocking + time window + URI > signing). > > > > > > Suggestions for improvements > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > ***Abstract > > replace "CDNI" by "CDN Interconnection". > > > > *** section 1: > > expand the first instance of CDNI into "CDN Interconnection (CDNI)". > > > > *** section 1: > > "Then, the document highlights the need for interoperability to > > exchange and enforce content delivery policies (Section 5)." > > I'd suggest replacing "for interoperability to exchange" by "for > interoperability to allow exchange" or by "for interoperability in order > to exchange" > > > > *** section 1.1: > > Do you feel that the two additional terms are really specific to the > use-case document (in which case their definition should stay in this > document) or are they likely useful in other documents (in which case > their definition should be migrated to the framework document)? > > Personally, I would say that those terms might be useful in other > documents/discussions (eg I am pretty sure we'd need to refer to the > "Delivering CDN" in other context). > > > > *** section 1.1: > > "Access CDN: > > A CDN that is directly connected to the End User's access." > > I think this definition needs to be a little more specific. "Directly > connected" does not mean "L2 connectivity" (because an on-net cache maybe > a few L2 hops away), nor does it mean "L3 connectivity" (because an OTT > CDN cache has IP connectivity to an enduser). I think you mean something > in between, more or less that the CDN and the access are within the same > IP administrative domain, or something close to that. Can you try refine > that definition? > > > > *** section 1.3: > > " o improve the experience for the End User; for instance delivery has > > lower latency (decreased round-trip-time between the user and the > > delivery server) and better robustness," > > To be more comprehensive in justifying the claims, how about: > > " o improve the experience for the End User; for instance delivery has > > lower latency (decreased round-trip-time and higher throughput > between the user and the > > delivery server) and better robustness (ability to use multiple > delivery servers)," > > > > *** section 1.3: > > "o reduce the Content Service Provider's (CSP) costs, such as > > datacenter capacity, space, and electricity consumption, as > > popular content is delivered through the CDN rather than through > > the CSP's servers." > > The current wording raises the question of "if it reduces the costs by > reducing expenses in the CSP datacenter, why does it not correspondingly > increase the cost by increasing expenses in the CDN (which the CDN > provider then charges back to the CSP)?" > > I think the gain is in the scale and effective pooling of CDN resources > across many CSPs. Could you refine the wording to explain why there is > indeed a net gain? > > > > *** section 1.3: > > Replace: > > " > > An example is depicted in Figure 1. Two CDN Providers establish a CDN > Interconnection. > > " > > with: > > " > > An example is depicted in Figure 1 where two CDN Providers establish a > CDN Interconnection. > > " > > (this is to minimize the redundancy with the sentence coming below: "CD= N > Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.") > > > > > > *** section 1.3: > > replace: > > " > > "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their > CDNs." > > with: > > "Independently, CDN Provider 'A' and CDN Provider 'B' agree to > interconnect their CDNs." > > this is to clarify that the A<->B agreement is not specific to the 1<->= A > agreement > > > > > > *** section 1.3: > > replace: > > " > > When a User Agent requests content from CSP-1, CDN-A considers that > delivery by CDN-B is appropriate > > " > > with: > > " > > When a given User Agent requests content from CSP-1, CDN-A may consider > that delivery by CDN-B is appropriate > > " > > > > > > *** section 1.3: > > replace: > > " > > CDN-A has delegated the handling of requests for CSP-1's content throug= h > the CDN Interconnection agreement, thus, the content is actually delivere= d > from CDN-B. > > " > > with: > > " > > Through the CDN Interconnection arrangements put in place between CDN-A > and CDN-B (as a result of the CDN Interconnection agreement established > between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the > request to CDN-B and the content is actually delivered to the User Agent > by CDN-B. > > " > > (the current wording suggests that all deliveries of CSP1 content would > be handled by CDN-B, which is typically not the case i.e. only a subset o= f > the requests are redirected thy CDN-A to CDN-B) > > > > > > *** section 1.3: > > replace: > > " > > CSP-1 benefits because it only needs to make one business agreement and > one physical connection, with CDN Provider 'A' > > " > > with: > > " > > CSP-1 benefits because it only needs to make one business agreement and > one technical arrangement with CDN Provider 'A' > > " > > (this is because the interfacing between CSP and uCDN comprises more > than "physical connection"). > > > > > > *** section 1.3: > > replace: > > " > > CSP-1 had also gone to the trouble of making a business agreement with > CDN Provider 'B' > > " > > with: > > " > > CSP-1 had also gone to the trouble of making a business agreement and > technical arrangemement with CDN Provider 'B' > > " > > > > *** section 1.3: > > replace: > > " > > But it does not want > > " > > with: > > " > > However, CSP-2 may not want > > " > > > > *** section 2.1: > > after > > " > > o without incurring additional transit and other network costs that > > would result from serving content from geographically or > > topologically remote Surrogates. > > " > > add: > > " > > o without incurring the cost of deploying and operating Surrogates and > the associated CDN infrastructure that may not be justified in the > corresponding geographic region (e.g. because of relatively low delivery > volume, or conversely because of the high investments that would be neede= d > to satisfy the high volume) > > " > > > > > > *** section 2.2: > > replace: > > " > > A large CDN Provider may also operate CDNs from several subsidiaries > (which may rely on different CDN technologies, see Section 4.2). In > certain circumstances, the CDN Provider needs to make its CDNs > interoperate to provide a consistent service to its customers on its whol= e > footprint. > > " > > with: > > " > > A large CDN Provider may have several subsidiaries that also each > operate their own CDN (which may rely on different CDN technologies, see > Section 4.2). In certain circumstances, the CDN Provider needs to make > these CDNs interoperate to provide a consistent service to its customers > on the whole collective footprint. > > " > > > > > > *** section 2.3: > > replace: > > " > > injected into the access network > > " > > with: > > " > > injected into the ISP network > > " > > > > *** section 2.3: > > replace: > > " > > There are mutual benefits to the Access CDN, > > " > > with: > > " > > There are mutual benefits to the ISP (acting as an Access CDN), > > " > > > > > > *** section 2.3: > > replace: > > " > > for example, QoS and reduced round trip time. > > " > > with: > > " > > for example, reduced content startup time or increased video quality an= d > resolution of adaptive streaming content. > > " > > (I don't think RTT is very meaningful to a CSP customer) > > > > > > *** section 2.4: > > The nomadic user is currently defined as "moving between CDNs" which is > sort of a self-serving definition to justify CDN interconnection. I think > we should rather define the nomadic user as "moving between access > networks" and then justify that leveraging local CDNs can bring a lot of > benefits. > > This requires the following text edits: > > s/who move between CDNs/who move between access networks/ > > s/moving between different CDN Providers/moving between different acces= s > networks/ > > > > *** section 2.4: > > replace: > > " > > which may reside > > " > > with: > > " > > which may be located > > " > > > > *** section 2.4:" > > I propose to remove the sentence: > > " > > The term "Nomadic" does not necessarily relate to geographic roaming. > > " > > because this point has already been fully (and better) clarified in the > preceding paragraph. > > > > > > > > *** section 2.4: > > replace: > > " > > the WiFi or mobile provider > > " > > with: > > " > > the WiFi or mobile provider (NSP B) > > " > > > > > > *** section 3.1: > > replace: > > " > > needs CDN capacities > > " > > with: > > " > > needs CDN capacity > > " > > > > *** section 3.2.1: > > The text mentions two options (use OS, use another CDN). I think the > section shoudl probably also mention the most obvious option (i.e. use > other surrogates in the same CDN). Or alternatively, clarify that the > considered situation is where there is a partial failure of some > surrogates resulting in the remaining surrogates being fully loaded. > > > > > > *** section 3.2.1: > > replace: > > " > > to both distribute load between origin servers and attempt content > acquisition from alternate origin servers when acquisition failures occur= . > When normal content acquisition fails, a CDN may need to try other origin > server options, > > " > > with: > > " > > to both distribute load between content sources and attempt content > acquisition from alternate content sources when acquisition failures > occur. When normal content acquisition fails, a CDN may need to try othe= r > content source options, > > " > > (I believe everywhere else we use "origin server" to refer to the OS of > the CSP and "content source" as the generic term for getting content > including origin server and uCDN) > > > > *** section 3.2.2: > > replace: > > " > > the selection of content acquisition sources should be considered. > > " > > with: > > " > > the selection of content acquisition sources should be considered and > facilitated. > > " > > (i.e. it is not just a matter of "thinking" about it: it must be > explicitly allowed or at leads made easier). > > > > > > *** section 4.1: > > "to serve a proportion of its traffic that requires HTTPS." > > can you include a reference for HTTPS? > > > > > > *** section 5: > > replace: > > " > > An important aspect of the above use cases > > " > > with: > > " > > An important aspect common to all the above use cases > > " > > > > > > *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line > 618, but no explicit reference was found in the text > > I'd suggest you add an explicit reference. For example, in "1. > Introduction" you could replace: > > " > > The document can be used to guide the definition of the requirements to > be supported by the various CDNI interfaces defined in [I-D.ietf-cdni- > problem-statement]. > > " > > by > > " > > The document can be used to guide the definition of the requirements (a= s > documented in [I-D.ietf-cdni-requirements]) to be supported by the set of > CDNI interfaces defined in [I-D.ietf-cdni-problem-statement]. > > " > > (BTW, independely of the reference issue, "the set of CDNI interfaces" > might read better than "the various CDNI interfaces"). > > > > > > *** The document has a disclaimer for pre-RFC5378 work, but was first > submitted on or after 10 November 2008. Does it really need the > disclaimer? > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From internet-drafts@ietf.org Fri Apr 27 19:14:52 2012 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 2D9D611E8093; Fri, 27 Apr 2012 19:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtE4b9dZTn5N; Fri, 27 Apr 2012 19:14:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB43511E808A; Fri, 27 Apr 2012 19:14:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120428021451.25703.44307.idtracker@ietfa.amsl.com> Date: Fri, 27 Apr 2012 19:14:51 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-framework-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 02:14:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnec= tion Working Group of the IETF. Title : Framework for CDN Interconnection Author(s) : Larry Peterson Bruce Davie Filename : draft-ietf-cdni-framework-00.txt Pages : 53 Date : 2012-04-27 This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, metadata exchange, and the acquisition of content by one CDN from another. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cdni-framework-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-framework-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework/