CDNI Working Group Minutes IETF-84, Vancouver, Canada, Jul 31, 2012 CDNI Session 2012-07-31 0900-1020: Regency D ============================================= About 100 people in the room, a few people on WebEx • Meeting notes captured by Gilles Bertrand, edited by Richard Woundy & Francois Le Faucheur Introduction and Agenda (Francois Le Faucheur, Richard Woundy) --------------------------------------------------------------- • Introduction by the WG chairs, and note well statement. • Agenda: o Day 1: base documents, metadata, logging o Day 2: request routing redirection, footprint/capabilities • Agenda bashing: no comments, no questions. • WG chairs reminders about the milestones: o Problem Statement and Use Cases drafts are in good shape. Problem Statement is in the RFC editor queue, and Use Cases has gone through IESG review with only one remaining DISCUSS in discussion with IESG. o Framework and Requirements drafts were paused, awaiting decisions on HTTP Adaptive Streaming (HAS). One of the goals of today's meeting is to make progress on HAS. o Logging and Control drafts are in progress, as Individuals I-Ds only. Update of these drafts is expected soon, but the deadline is approaching (December 2012) and will be difficult to meet. o The Request Routing/Redirection interface is subject to multiple I-Ds but not enough progress and convergence towards a WG solution o The Request Routing/Footprint&Capability interface is in progress but there are many I-Ds, and more design team progress is required. o The Metadata draft is making good progress. Framework: draft-ietf-cdni-framework-01 (Larry Peterson) --------------------------------------------------------- • The following items were addressed in the first WG draft: o Fixed terminology (“delivery CDN”) o obsoleted RFC 3466 o Defined the trigger interface o Called out HTTP Adaptive Streaming (HAS) issues o Added content acquisition from multiple upstream CDNs o Identified cross interface concerns o Added "check with me flag" for metadata • Items to be addressed in next version include the following: o Define CDNI-wide data model o Summarize consensus on HAS o Make design recommendations • Francois Le Faucheur: re CDNi-wide data model, how much should go in cdni-framework vs cdni-metadata? • Larry Peterson: this is TBD but I feel it is worth discussing in cdni-framework since this should be leveraged by multiple interfaces. Models for Adaptive Streaming Aware CDNI: draft-brandenburg-cdni-has-00 (Ray van Brandenburg) --------------------------------------------------------------------------------------------- • Francois Le Faucheur reminded attendees that there has been three design team meetings on HTTP Adaptive Streaming (HAS) and that the charter calls for prioritizing work on what is “required” versus what is “nice/optimization” • Martin S/Francois pointed out there is IPR that has been declared against this document. • Ray van Brandenburg discussed the purpose of the draft, which is to define terminology, present unique challenges that HAS introduces on CDNI, introduce options on the level of HAS awareness in CDNI, and provide recommendations on the options to be supported by the WG. • Support for HAS is a requirement. Taking a pragmatic first step, "making HAS work", avoids unnecessary optimizations. • Ray discussed options and recommendations for file management (option 1.1, no HAS awareness), for content acquisition (option 2.1, no HAS awareness), and for dealing with request routing and manifest file (option 3.1, no HAS awareness – required; option 3.2, manifest file rewriting by uCDN – optional). o Note: last bullet of slide 5 should say “Option 2.2 can be considered for re-chartering after initial solution is completed”. o Richard Yang asked whether Option 3.2 means that CDNs should support all HAS formats. Francois clarified that option 3.2 may or may not be used by uCDN at its discretion and is transparent to CDNI operations, and there should be no impact on the CDNI interfaces.   • Ray discussed options and recommendations for logging (option 4.1, per-chunk logging – required; option 4.2, include content collection identifier – optional; option 4.3, common compression – optional). o Ashok Narayanan asked if there is not a one to one mapping between the CCID and URI, so that CCID might not be strictly needed. o Francois Le Faucheur indicated that with some HAS schemes (eg HLS) it is not always possible to correlate different representations simply from their URIs because they can use arbitrary URI path. So CCID is needed. • Kent introduced options and recommendations for URL signing and recommendations for HAS. Option 5.2, flexible URL signing by the Content Service Provider and upstream CDN, is recommended because it provides some protection and does not introduce requirements on the downstream CDN. o Note: last bullet of slide 12 should say “Flexible URL Signing (#2) is recommended because …”. • Ray introduced options for content purge (with a possible recommendation of option 6.1, do nothing – mandatory, and option 6.2, include CCID for purge – optional) and requirements for capabilities advertisement. o Rich Woundy asked whether the recommendation (for both logging and content purge) is whether CCID is mandatory to implement but an optional value, or optional to implement. Francois and Ray responded that it is an optional implementation. • Bhumip asked whether traffic management (as discussed in Bhumip’s recently posted I-D) has been discussed for HAS. • Ray & Francois: responded that, as far as we could tell, the traffic management mechanisms mentioned there had to do with datapath acquisition which is out of scope for CDNI. • Richard Yang asked two questions about flexible URL signing: (1) if CDNI places signing-related requirements on CDN, will that impose additional requirements on the CSP? And (2) if signing the invariant part of URL, but chunks sometimes are progressively available, what is the expiration time for signatures? o Issue (1): Kent pointed out that if the CSP does not do URL signing, the uCDN can do it on the CSP’s behalf. Richard raised the case where the content provider provides the manifest file directly to clients, while the chunks are retrieved from a CDN. Kevin Ma stated that some aspects of content delivery do not have to do with CDNI interfaces. Francois clarified that URL signing requires work and specification for CDNI regardless of HAS anyways, if you want URL signing to work across CDNs. So there is a requirement (independently of HAS) for standardized URI signing scheme(s). o Issue (2): Kent noted that it is a generic issue also raised by Kevin on the list. Francois added that this point is valid, but already addressed in the draft. o Roy asked whether there is not a need for a session ID in addition to the ? Ray replied yes, and it is already detailed in the draft (although it was not mentioned in the slides). o Matt pointed out that the metadata of the manifest and of the chunks can differ, so you may end up in situation where the dCDN can handle the Manifest but not the chunks. Ray agreed this is a good point to add in the draft and can be addressed via capabilities. o Ben N. Jenkins offered a clarification on issue 5: the draft does not discuss a specific URL signing method, but discusses the generic concept. • Francois conducted a hum test for all of the HAS-related recommendations: o “Do you support moving ahead for the WG this draft's recommendations?”: Moderate hum o “Do you feel the WG should not move ahead along the lines of this draft’s recommendations?” No audible hum sound.. o Conclusion from chairs: this shows a reasonable support and no objection • Ray stated that next steps include reflecting HAS decisions into framework, requirements, logging and control drafts, as well as cdni-has document clean up. Francois noted that the status of this document will be addressed later (in general we feel the analysis of cdni-has should be retained somehow for the record and the question is what is the best repository). Content De-duplication: draft-jin-cdni-content-deduplication-optimization-01 (Bhumip Khasnabish) ------------------------------------------------------------------------------------------------ • Bhumip introduced the problem: while CDNI content is identified by URL, the same content might be addressed through several URLs. Space is wasted if the same content is uselessly stored several times in a CDN. • The solution proposed is a content naming approach; the content identifier would be included in the metadata. • The recommendation of the draft is to define a unique content identifier within the scope of CDNI. • Francois commented that this is an optimization; if this mechanism is not supported by CDNI, things will work, just less efficiently. • Ben Niven-Jenkins felt the need to study the problem more before including these optimizations. A significant question is how content revalidation would work. • Francois pointed out he’s also posted a similar question on the list about how purge would work. So recommendation is to progress these questions into dedup I-D and then WG can make a decision. Metadata: draft-cjlmw-cdni-metadata-00 (Matt Caulfield) -------------------------------------------------------- • Matt described the merge of Ben and Matt's Metadata drafts. • Matt recapped on the role of the Metadata draft, with emphasis on providing acquisition details and delivery policies. • Matt reviewed the design principles for Metadata and the proposed data model, including Metadata properties. • Next steps include choosing XML vs JSON, defining extensibility rules, and cleaning up the inheritance rules. • Francois called for WG feedback on the choice of XML vs JSON. Metadata: draft-ma-cdni-metadata-03 (Kevin Ma) -------------------------------------------------------- • Kevin introduced requirements on the Metadata interfaces. • Kevin describes a proposed Metadata data model, with a flat structure and longest prefix matching (which solves issues that could occur with wildcards). • Discussions are in progress to merge with the merged Matt/Ben Metadata draft (cjlmw-cdni-metadata ). • Richard Yang asked whether there would be two copies of Metadata for “www.example.com” and “example.com”? Kevin responded that the Metadata values may be references instead of copies.   CDNI Session 2012-07-31 1520-1650: Georgia B ============================================= • About 80 people in the room Metadata discussion continuation -------------------------------- • Francois does a quick recap on metadata. • Francois conducts a hum test on accepting cjlmw-cdni-metadata as a WG document: o 'if you feel that the cjlmw-cdni-metadata draft is ready to be accepted as a working group proposal": strong hum o 'if you do not feel that the cjlmw metadata draft is ready to be accepted as a working group proposal ': silence. o Conclusion from chairs: good support for the adoption of the metadata draft as a WG document and no objection. HAS logging: draft-lefaucheur-cdni-logging-delivery-01 (Francois) ----------------------------------------------------------------- • Francois: o recaps that there are two non-WG documents about logging for the moment. Gilles' one relatively broad in scope. Francois' one that detail some things that were not detailed in Gilles' draft and specificities for HAS logging. o Two fields to be added in any HTTP log records: user agent, information to indicate if URL signing was performed or not o Structure of the logging files with (1) headers. Francois details the fields that would fit in that header. (2) record digests (3) log file footers. o stresses the importance of a customizable log format o details HAS aspects for chunk-based logs updated in accordance with recommendations of Brandenburg-cdni-has. So, two extra fields that we may want to log: CCID and session ID. o details the impact on the metadata interface and on the Footprint & Capabilities advertisement interface. • Question from Richard Yang: (1) port number not present in the fields presented. (2) log of URIs hidden inside message body (3) total bytes not appropriate for 95th percentile type of billing (4) server centric logging: user centric QoE metrics (5) why use footer and not include in the header? • Francois: please send an e-mail on the mailer listing all these suggestions/comments • Gene Golovinsky: logs are generated for machines, not for humans, right? • Francois: debugging is one of the usages where human readability would matter.   • Gene Golovinsky: why not use syslog to support CDNI Logging? • Francois' answer: syslog is definitely a candidate protocol. CDN lies at the boundary between application and network. Some format/protocols are much more natural to application people (Webservices,W3C,Apache/Squid). Some format/protocols are much more natural to network people (Syslog). My perception is that folks operating CDNs are typically more “application people” than “network people” • Roy Peterkofsky: no dCDN identifier in the logs for the moment. Would be useful. • Francois: Agreed. • Ben Niven-Jenkins: footer is actually pretty valuable. => example: did I receive the whole log file or not? • "?" FTP is not a secure protocol. Not adapted for transfer of logging.   • Gilles does a quick update on the draft-bertrand on logging: next version planned for mid-September. Generally agrees with proposals in draft-lefaucheur-cdni-logging-delivery, so no expected issue with integrating that material. Routing Request Redirection for CDN Interconnection,draft-he-cdni-routing-request-redirection-02: Yunfei Zhang -------------------------------------------------------------------------------------------------------------- • presents the main changes in his draft • Remark from Martin Stiemerling (AD): IP address seen at DNS level is the one of the resolver • Yunfei proposes to have a link to the related metadata in the request routing redirection messages • Yunfei describes data passed in CDNI request routing responses • Yunfei  describes a Restful interface between the CDNs • Haibin Song: This interface could also be asynchronous and the dCDN provide in advance the URI before the request comes • Yunfei details next steps: submit a detailed protocol specification for this interface CDNI Request Routing, draft-lelouedec-cdni-request-routing-00: Yannick Le Louedec --------------------------------------------------------------------------------- • Yannick recaps the work that led him to publish this draft: he derived all the possible call flows to see what we really need to exchange to make CDNI work (bottom up approach) and identified the best framework this way, while trying to be as compatible as possible with existing assumptions of the WG. • Yannick explains that a key point in the framework is that the request routing terminology is not clear enough in the current version. There are three different parts the CDNI request routing interface, (1) the request routing/ footprint & capabilities advertisement, (2) the request routing / redirection interface, and last (3) the operations to forge and send the redirection request.. The next step is to reflect this consensus in the framework. These steps were discussed and refined in an informal side meeting. CDNI Request Routing Redirection with Loop Prevention,draft-choi-cdni-req-routing-redir-loop-prevention-00: Taesang Choi ------------------------------------------------------------------------------------------------------------------- • Taesang presents the problems that his draft addresses: req routing procedures, loop prevention, and operational requirements related to request routing.
Taesang proposes to have a CDN provider ID that uniquely identifies a CDN provider based on an ASN and a maximum number of redirections • Taesang describes several examples (HTTP based iterative method, DNS based method...); to illustrate ways the CDN provider ID could be conveyed • Taesang describes the proposed loop avoidance mechanism on an example • Taesang stresses the fact that user proximity is not the only element to be considered for routing a request (availability etc matter) • Wei Ni: is there a risk to have too long URLs, exceeding browser limitations? • Taesang answer: that's why we propose to carry this identifer in the query string rather than in the URL in itself. CDNI Request Routing: Footprint and Capabilities Semantics (update on Semantics I-D and progress of Design Team), draft-spp-cdni-rr-foot-cap-semantics-01: Jan Seedorf, ------------------------------------------------------------------------------------------------------------------- • Jan reminds decisions from Design Team made before Vancouver for footprint / capability advertisement: o detection of 'cheated" advertisement by dCDN does not have to be done in real time. o Focus on the main use cases to simplify things. • Jan reminds the outcome of the Design Team taken during side meeting in Vancouver on Monday: ◦ Footprint could be “willingness to server” + “quality information” ◦ Part of the footprint advertisements will occur in contractual agreements ◦ Advertisement should not include highly dynamic QoS information ◦ monetary costs are probably out of scope of the dCDN advertisements • Jan reminds the open issues ◦ Still no definitive agreement on how to define the footprint notion ◦ advertisement of dCDNs resources probably out of scope ◦ A lot of the footprint advertisement information will probably be carried through contractual agreements. What actually do we need to carry through the request routing/footprint capability advertisement ? ◦ What capabilities would be useful / required. Not yet defined. How can we express them? • Jan presents next steps: he requests comments from the WG, have more design team meetings • Jon: the hum taken in Design Team meeting was a bit expeditive: choice at the detriment of flexibility. Francois: flexibility is good, but it is quite different to advertise reachibility from advertising ressources • Jon: we need more information from the market. we do not want to put unnecessary constraints at this stage • Douglas: we constantly see inconsistencies about the identification/geolocation of IP addresses • Enrico Marroco: footprint not yet clearly understood • Jan Seedorf : uCDN can decide if another competing dCDN has better quality than the selected one. • Enrico Marroco: Location of caches = !1 metric. 
• Emile Stephan: Semantics of contracts defined by the WG?
• Jan Seedorf: not really, we don't want to do that • Martin Stiemerling: we do protocols, so no legal or commercial stuff here • Enrico Marroco: am i gonna advertise everything? 
• Jan Seedorf: willingness to serve needs more info (anyway, nothing highly dynamic) • Emile Stephan: would it help to reword "contractual agreements" into "SLA"? • Matt Caulfield: capability is tied to metadata • Jan Seedorf: might be, but can be also tied to a subset of footprint • Jon Peterson: intraCDN topic: how will dCDN decide what to advertise ? 
• Jan Seedorf: we don't want to define that, but we want to give flexibility. 
• Richard Woundy: There are other occurrences where the IETF defines a protocol on how to distribute some information without specifying how to glean/generate that information. Answer could be policy, magic software, configuration,… • Jon Peterson,: yes, but IETF needs to ensure it is indeed possible to glean/generate that information. • Some more discussion took place on relationship between contract, SLA, dCDN selection and footprint and capabilities advertisement, but this was not conclusive. • Gilles: I would really like to see a clear use case definition for the Footprint & Capabilities advertisement. • Kevin: could we separate footprint / capabilities to move forward on the capabilities aspect. • Martin: as AD I recommend that the discussions on Footprint Capabilities be brought onto the whole group list rather than only within the design team • Francois: I suggest that the Design Team meeting takes a use case approach (ie first defines one or a few key use cases) and derive what is needed for every use case. Other items ------------ Internet-Drafts related to actual solutions/protocols for Footprint&Capabilities Advertisement (draft-song-cdni-slr-based-footprint-01, draft-seedorf-cdni-request-routing-alto-02, draft-stephan-cdni-alto-session-ext-01) were not discussed because the WG time was allocated in priority to the topic of semantic definition (ie the Design Team charter) which needs to progress before actual solutions/protocols can be meaningfully specified and evaluated. draft-shin-cdni-request-routing-sdn-00 (which was tentatively on the agenda if time remained) was not discussed because of lack of time.