CDNI Working Group Minutes IETF-85, Atlanta, USA, - Chaired by Francois Le Faucheur and Ray van Brandenburg (since Richard could not attend) - Meeting RAW notes captured Marcin Pilarski, edited by Francois Le Faucheur CDNI Session 2012-11-07 13:03-14:32 EST: Salon E ============================================= - about 50 people in the room, a few people on Jabber, a few people on WebEx Introduction and Agenda (Francois Le Faucheur, ... ) --------------------------------------------------------------- - Introduction by the WG chairs, and note statement. - Agenda review - See chair slides 1) WG chairs reminders about the milestones: - CDNI Problem statement - first RFC is in place - CDNI Use Case is in 48auth state and will come out very soon - cdni-framework stalled for a while. New rev with significant work to come out shortly after this meeting, so progress has resumed. - draft-brandenburg-cdn-has will go for Individual Submission - cdni-requirements to be revved up to align to HAS decisions and to latest progress of interface specs --> Kent Leung to reach out to interface authors to define interface specific requirements with them. - cdni-logging not progressing as fast as expected. needs more attention. - cdni-triggers - progressing well. But the question of whether we need more as a Control Interface is not closed yet. - redirection interface - has not been moving as fast as we hoped. But was revved up recently and is going in the right direction, but need to speed-up. - Footprint & Capabilities - has been moving slowly, however some progress lately. Needs more progress. - cdni-metadata is progressing well and on track to meet charter date - proposal from Chairs to use common acronym sets to refer to the CDNI interfaces: --> Francois to drive this on the mailing list. *Daryl Malas: Which documents will define the acronyms? *Larry & Francois: the Framework. *Daryl: agreed Framework: draft-ietf-cdni-framework-01 (Larry Peterson) --------------------------------------------------------- -see slides - A major revision of framework is in progress - to be posted after the Atlanta meeting (very soon). This revision will address comments from mailing list and alignment to HAS decisions, however still open issues like: - Redirection Loop Prevention - long tail - control of logging Info (Metadata vs Control Interface) *Francois: Would you agree to move in cdni-framework the documentation of which interface (Control or Metadata) is to be used for signaling of logging formats, once the decision has been made? *Emile: yes, we may do it in framework *Larry: fine *Daryl Malas: normative-like language is currently used in Framework while this is an Information document. *Larry: cleaning of "must(s)" in new revision is already in progress. Will search for all "must" *Francois: is something significant missing from the framework draft ? *Jan Seedorf: What other protocols will work with respect to redirection, in addition to HTTP and DNS? *Francois: We should stick to HTTP and DNS for now, if others happen to also be supported via the Redirection interface, this is good, but not a specific objective. *Ben Niven-Jenkins: maybe the right approach in the framework is to describe that there are two classes of redirection: DNS and application-level, where HTPP is a specific example of application-level. *Francois: That is a fine approach for the framework, but as far as the Redirection interface we do not have an objective to support other protocols than DNS and HTTP. Right? *Ben: Agreed. *Francois: Any other opinion? *No other opinion, so agreed to support only DNS and HTTP redirection at this stage. Content De-duplication for CDNi Optimization, draft-jin-cdni-content-deduplication-optimization-03: Bhumip Khasnabish --------------------------------------------------------- - see slides - problem of de-duplication explained with 3 scenarios. - survey up to 60% data stored is duplicated. *Marcin Pilarski: what are the assumptions behind these numbers because that does not match at all what I see in my environment *Bhumip: will be explained in this draft or in separate draft *Francois: If the same asset is distributed by 10 CSPs, do you consider that as 1 content that can be de-duplicated or as 10 contents? To me this is 10 contents that can not be reduplicated. I don't buy the 60% figure you claim, so I suspect you may have counted the above as 1 content to de-duplicate, when de-duplication should only be done within a given CSP in my opinion. *Francois: will the separate instances of a given asset distributed by different CSPs share a single EIDR or separate EIDRs? *???: EIDR allows either option. *Jon Peterson: I support the idea of advertising an EIDR for content in CDNI Metadada as this is likely to be useful *Daryl Malas: Also support this idea *Ben Niven-Jenkins: content reduplication is worth continuing investigate in the working group but needs more understanding and it is more of a Nice-to-Have than a Must-have so we should not hold back the other interfaces to incorporate it. *Francois: Let's do a show-of-hand on how to proceed with content deduplication considering the following options: - Option 1 - decide this is not a significant problem for CDNI - we do not bother and stop working on it inside the WG (for now) - Option 2 - decide it is a nice-to-have, but is not crucial for initial versions of CDNI interfaces. We continue the work on it inside the WG, but do not aim to support it in first version of the CDNI interfaces. - Option 3 - Option 2 + advertise a "content ID" in first version of Metadata interface (with understanding it will be useful but not sufficient to support content deduplication). - Option 4 - decide this is crucial and there is no point releasing CDNI interfaces without it. We continue work on it in WG and, if needed, we hold CDNI interfaces to support this. Actual Show of Hands: - Option 1: 4 people - Option 2: ~20 people - Option 3: 5 people - Option 4: 0 people Best practices and Requirements for delivering Long Tail personalized content delivery over CDN Interconnections, draft-krishnan-cdni-long-tail-04: Ramki Krishnan (10 mins) --------------------------------------------------------- - see slides - Draft address the problem of content that shoudl not be cached by dCDN. - draft proposes the method using CDNI interfaces so as to not redirect to dCDN. *Jan Seedorf: why is that in scope with CDNI since what you want to achieve is to not do CDNI redirection? *Ramki: because we propose to use metadata interface for dCDN to notify uCDN to not redirect *Kevin Ma: I don't see why this is needed since the uCDN can decide itself to not redirect to dCDN *Francois (as individual): I agree with Kevin i.e. uCDN may take this decision himself, because he has the necessary information to make the right decision. Also, as explained on the list (i) even if we implemented the proposed solution, I am not sure it will work well e.g. in case content becomes popular after it has been declared long tail and (ii) the proposed solution assumes use of interfaces differently from how they are designed (e.g. metadata interface in opposite direction). *Martin Siemerling (as Individual): is longtail the right term to use ? *Ramki: yes, it is a well accepted term for non-popular content. *Francois: Let's do a show-of-hand on how to proceed with Long Tail, considering the following options: - Option 1 - decide this is not a significant problem to solve and drop long tail discussion from WG (for now) - Option 2 - decide this is a significant problem, and continue to work on that Actual Show of Hands: - Option 1: 20 people - Option 2: 2 people. CDNI Metadata, draft-ietf-cdni-metadata-00: Matt Caulfield (10 mins) --------------------------------------------------------- - see slides - What is the default set of metadata that all CDNs must support to interoperate ? Current matadata: Acquisitions sources, location, Time Window, Protocols ACLs, Authentication. *Matt Caulfield: are other metadata needed *Francois: as discussed on the list, we also want "ignore query string for caching" and "check-with-me" *Matt: agreed *Bhumip: for what type of content (or video) above metadata has been designed for ? *Matt: Mostly video *Bhumip: but what type of video, because additional metadata may be needed *Francois: Bhumip, I suggest you document on the list what additional metadata you want to propose *Matt: we need to decide between XML versus JSON encoding. Anyone have an opinion? *Jan Seedord: very related with discussion in Design team on capability advertisement. *???: in fact, this should be a cross-interface decision. *Matt: agreed *Francois: a question to the AD: is there a general IETF view, position or trend on this? * Martin as AD: any WG is free to choose the encoding they see best fit, however JSON seems to be more commonly selected lately. *Bhumip: can you document the pros and cons of JSON vs XML for CDNI? *Matt: we could but those are the generic generic pros and cons and not specific to CDNI CDNI Session 2012-11-08 13:00-14:59 EST: Grand Salon D ==================================================== about 45-50 people in the room, a few people on Jabber, a few people on WebEx CDNI Metadata (Continuation), draft-ietf-cdni-metadata-00: Matt Caulfield (10 mins) --------------------------------------------------------------- *Matt Caulfield: Should CDN capabilities be tied to metadata ? *JanS: yes, that was the recommendation established by the CDN footprint design team *Matt: OK, we will address in next rev - Next steps as in presentations, no more comments on document. CDNI Logging , draft-bertrand-cdni-logging-02: Emile Stephan (10 mins) --------------------------------------------------------------- -see slides - updated twice since Paris meeting - proposal to support signaling of logging formats in Control Interface, but this will be discussed separately at the end of the presentation. - CDNI logging information and structure explained (slide 8) - CDNI logging fields proposed (slide 9) - CDNI records and triggers proposed (slide 10) - CDNI logging file format proposed (slide 11) - Next step: propose to adopt draft-bertrand-cdni-logging-02 as WG document *Larry Peterson: why we do need to exchange log for Purge? *Emile: ??? *Kevin Ma: The Triggers interface provides a status report, so no need to also have separate logs. *Francois (as individual): we do need to expose internals of dCDN (in case of Purge) because that will be exposed in Purge status. The uCDN should not aim at trouble-shooting what happens inside the dCDN *Emile: we must provide this information for troubleshooting issues. Troubleshooting is important for us. *Ray van Brandenburg (as Chair): it appears we do not have agreement on this, but need to move on. * Francois: Let's do a show-of-hand for WG adoption of the document: - Option 1: draft-bertrand-cdni-logging is ready to be accepted as WG document - Option 2: draft-bertrand-cdni-logging is not ready to be accepted as WG document Actual show-of-hands: - Option 1: 15 people - Option 2: 0 (zero) *Francois- let's discuss the question of which interface is to used to signal CDNI logging formats *Larry Peterson: I favor use of Control Interface because so far a significant distinction between Control and Metadata has been that Control was used when an explicit confirmation was needed about completion of the action, and we want to know that logging format control has been taken into account *Kevin Ma: since the set of logging fields is different for different content sets, that matches metadata interface *Ben Niven-Jenkins: this is an architectural question: metadata is about content configuration information, while control is about infrastructure configuration information. Since logging format is to be defined at the granularity of content sets, it is more of content configuration and therefore in scope of metadata. *Jon Peterson: I agree this is an architecture question, and because there are different perceptions of the architecture there are differing conclusions. *Emile: logging is not only about content, it is also about infrastructure. *Kevin Ma: regardless of whether it is Static or Dynamic, metadata is still good place to support the signaling of logging formats *Emile: ? *Martin Siemerling (as individual): my opinion is that maybe it could be supported using both interfaces i.e. where the Control interface could be used to signal templates and Metadata interface could be used to associate the template to content sets. *Kevin Ma: the Metadata interface already supports such an indirection since it can point to resources that are anywhere (via links) so it can directly point to templates populated by uCDN that need not be exchanged over CDNI control. *Martin as individual: yes, that may be an option. *Francois: Let's do a show-of-hand: - signaling of Logging format by Metadata interface - supported by 15 people - signaling of Logging format by Control interface - supported by 5 people *Francois: it seems we need more discussion to close on decision. Chairs will aim at driving discussion on this, possibly with specific webex session to facilitate convergence. CDNI Triggers , draft-murray-cdni-triggers-01: Rob Murray (10 mins) --------------------------------------------------------------- - see slides * Kevin Ma: note into draft that we should do it NOT out of order, because then we get into trouble. * Rob: Aim for adoption before IETF86. URI Signing for CDNI, draft-leung-cdni-uri-signing-01: Kent Leung (10 mins) --------------------------------------------------------------- -see slides * Jan Seedorf: why did you decide for hop by hop resigning with HTTP redirection? what is the trust model ? * Francois: the CDNI framework documents the hop-by-hop trust model (chain of trust) as the general model for CDNI. So hop-by-hop resigning actually fits the CDNI model well. *Kent Leung: trust model explained with shared key. And with HTTP redirection, you need to resign because of URI rewrite *Kevin Ma: some URI signing algorithm could potentially allow to not resign even in case of URI rewriting *Kent: true if they exclude the rewritten part. *Jan: what is more deployed between sym/asym key ? *Kent: both are deployed today. Routing Request Redirection for CDN Interconnection,draft-he-cdni-routing-request-redirection-03: Ben Niven-Jenkins (10 mins) --------------------------------------------------------------- -see slides - Changes since -02 explained. - example call flow - DNS redirection - HTTP Post - cacheability defined by HTTP headers not by body itself. - questions: a) how to aligh with DNS terminology ? b) WG adoption ? *Matt Caulfield: Why does the draft only discuss recursive redirection mode? *Francois: by definition, iterative redirection means that the uCDN does not query the dCDN, so the Redirection interface is not used in iterative *Matt: why not simply use the protocol themselves (i.e. HTTP and DNS) for uCDN to query dCDN instead of defining a web services interface? *Ben: for several reasons including (i) it is not always possible/obvious to convey between uCDN and dCDN inside existing protocol all the necessary fields and (ii) it is likely we may want to support other protocols than DNS and HTTP in the future and a generic interface allows that more easily (if not already as is). Francois: Regarding WG adoption, the draft is going in the right direction, but is still a little sketchy, so it may be a bit premature to adopt as is. My proposal is to have authors commit to a next version shortly e.g. in 4 weeks from now. Then we can poll for WG adoption on the list (say one week after new rev is posted) so we don't unnecessarily wait until next IETF. Ben Niven-Jenkins: yes, I commit to publish next version in 4 weeks. [Note: this means by 6 Dec 2012] CDNI Request Routing Redirection with Loop Prevention,draft-choi-cdni-req-routing-redir-loop-prevention-01: Taesang Choi (10 mins) --------------------------------------------------------------- - see slides - Changes since -00 version explained. - Experimentation of loop prevention - explained. a) 4 different CDN labs in testbed b) continuous redirection possible, controlled by hop-counts. *Ben Nivens: there is no hard limits in protocols, so where do your hard hop-count limits come from? server-side or client side? *Taesang: it is client side limited (by client implementation) c) trace of HTTP 302 - case presented - Proposed next step: merge into draft-he-cdni-routing-request-redirection - Answers to chair's questions (asked via email) presented at slide 11. o Loop prevention mechanism is believed to be well understood o Loop prevention mechanism need not impact other interfaces *Francois: while loop prevention is clearly needed in the long run, it is not strictly mandatory for first version of our interface specs (since it only plays in highly meshed CDNI environments). However, if it is well understood and does not impact other interfaces, it can be incorporated in the request redirection document. Question to authors of draft-he-cdni-routing-request-redirection: have you reviewed this document and are you willing to incorporate in next rev? *Ben: I read earlier version but not latest so it is difficult to sense how much it would take to incorporate. I recommend we first publish new rev of draft-he-cdni-routing-request-redirection and then work on incorporating loop prevention. *Taesang: we understand, but if possible it would be nice to incorporate right away *Ben: we can work in parallel and see how that pans out CDNI Request Routing: Footprint and Capabilities Semantics (update on Semantics I-D and progress of Design Team), draft-spp-cdni-rr-foot-cap-semantics-02: Jan Seedorf (20 mins) --------------------------------------------------------------- - Status Quo from IETF84 presented. - contractual information advertisment question ? a) details of cdni contracts are not clear at this point of time b) what those "contract" means for us as standarization body ? c) Focus at UseCase (by Emile, Anne, Yannick) to drive discussion - posted already at mailing list d) agreement on subset information (delivery, acquisition, redirection, etc...) *Jan: what should be the timeframe for conclusion of the footprint & cap advertisement design team ? *Enrico Marocco: in some cases dCDN cannot advertise to uCDN due to some peering/transit link contract. *Chair: please bring this to mailing list, because not everyone understands the issue in that scenario *Jon Peterson: I will help document it *Jan: to move forward please bring this UseCase to design team. *Martin: need to consider this UseCase. *Jon Peterson: we don't want to prevent any solution, because that may limit the market in the future, and the market do not exists yet. So we should be open to different approaches. *Martin as AD: if the design team can converge on one approach that is good, but if it cannot then we should have design team document more than one approach. *Chair: there has been two viewpoints in design team wrt Footprint semantics, which have been discussed multiple times, but which have not been able to converge, or accept that one would concede. This has been holding progress. So if that is what it takes to allow progress, then the design team could document more than one approach to semantics. And then we can hope that the multiple semantics can be supported by same protocol, but if not possible we may end up with more than one protocol. Note that 2 semantics is better than 4. Chair: question to AD: do you give blessing for DesignTeam to have flexibility to define more than one Footprint semantics if needed?. Martin as AD: yes, fine with me. *Martin as AD: Good that you have a DesignTeam, but the rest of WG need to get hand on this as well. So I encourage rest of the WG to review and input. CDNI Capabilities Interface, draft-ma-cdni-capabilities-00: Kevin Ma (10 mins) --------------------------------------------------------------- - see slides - dCDN selection UseCase - explained - proposed set of capabilities have been incorporated in Design Team semantics work - capability interface - explained - Next Steps - slide 3 - comments - none from the room. Intra-CDN Provider CDNi Experiment, draft-chen-cdni-intra-cdn-provider-cdni-experiment-00, Bhumip Khasnabish: (5 mins) --------------------------------------------------------------- - see slides - 10 provinces in China, China Telecom as CP. - Experiment description - explained - logging out of scope - results - explained - lessons learned - explained Summary: Chair: Thank you. This has been a productive meeting NO remaining time for following drafts that had been put tentatively on the agenda: a) Experiments on HAS over CDNI, draft-famaey-cdni-has-experiments-00, Ray van Brandenburg: (5 mins) b) CDNI Control Operations, draft-stephan-cdni-control-operation-00:Emile Stephan (5 mins) c) CDNI Request Routing with ALTO, draft-seedorf-cdni-request-routing-alto-02: Jan Seedorf (5 mins)