CDNI WG Minutes Meeting: IETF-81, Thursday, 17:40 -- 19:40, Quebec City, 2011-07-28 Location: Room 206B, Hilton Quebec Chairs: Francois Le Faucheur and Richard Woundy Note takers: Daryl Malas and Ray van Brandenburg, edited by Rich Woundy Attendance: 112 people, according to the blue sheets [These minutes represent a condensed summary of the meeting. Fully detailed discussions can be heard on the audio recording of the meeting, currently found at http://www.ietf.org/audio/ietf81/ietf81-206b-20110728-1256-pm.mp3, starting at offset 04:46:15 and completing at offset 06:51:34.] Chairs open the meeting at 17:40. Richard Woundy briefly recalls concept of CDNI: Allow CDNs to interwork without changing internal CDN operation. Richard presents meeting agenda and list of WG milestones. Presentation - CDNI Problem Statement Speaker: Ben Niven-Jenkins Draft: draft-jenkins-cdni-problem-statement-01 Materials: http://www.ietf.org/proceedings/81/slides/cdni-7.pptx Ben briefly introduces the drivers behind CDNI: NSPs are increasingly deploying CDNs. However, different NSPs operate different, independent, CDNs. Content providers want to make their content available to a wide geographical region but may not want to have to deal with multiple NSP CDNs. NSP therefore need the ability to interconnect their CDNs. Ben describes the CDNI reference model, consisting of four separate interfaces: a Control interface, a Logging interface, a Request Routing interface and a Distribution Metadata interface. All other interfaces are out of scope of the WG. These include, but are not limited to: content ingestion from the CSP to a CDN, content acquisition between two CDNs, content delivery to end-users, content transcoding, DRM and internal CDN protocols. On the shape of the document, Ben explains that the document started out as a way to document the CDNI problem space and as a holding area for all kinds of information leading up to WG creation. He proposes to clean up the document and focus it on articulating the CDNI problem space. In order to do so, he proposes to: - Remove the CDNI WG non-goals - Remove the CDNI WG prioritizing - Remove sections on related standardization work in other SDOs, optionally retaining the gap analysis Richard Woundy asks the room whether they have any comments on this. * Discussion Eric Burger: Taking text out of a document is easy. Leave it in for now, we can always get it out later. David Harrington: WG prioritization is important. If someday the WG dissolves, it is important that this information is retained. Serge Manning: Non-goals should be documented somewhere. Eric Burger: We could use the charter for documenting those. The charter is archived forever. David Harrington: I agree with Serge. Leave it in so people from other SDOs can take a look at it. That way they understand why the we do certain things and leave out other things. Eric Burger: We could include a pointer to the charter in the document. Ben Niven-Jenkins: Non-goals are not fixed. What is a non-goal now, might not be a non-goal in two years. David Harrington: That depends on the reason for things to be a non-goal. If it is related to the nature of the IETF, than those will not change. Kent Leung: From a readability perspective, referencing a charter is not very convenient. Spencer Dawkins: If you use a link to a charter, remember that URLs might change. The tools team could help. David Harrington: How about putting in an appendix, with a note to the RFC editor stating remove this from the document upon publication? Richard Woundy: Agree, let's consider that. ** HUM TEST: Who thinks we should place CDNI non-goals, prioritizing and related standardization work in the appendix? ** HUM RESULT: The room agrees with the notion of placing the information in the appendix, with a note to the RFC editor to remove it upon publication. Ben Niven-Jenkins explains that the milestone for publishing the CDNI problem statement draft is December 2011. This means that there is only one meeting left. He therefore proposes to adopt the current draft as a WG document and have a version ready for WG Last Call by the November meeting. Ben presents the current open issues: - Should the reference model explicitly show that content acquisition by a dCDN surrogate could make use of the CDNI Request Routing service in the uCDN? - Are the set of protocols listed in the current draft sufficient to implement CDN? - Does the current draft describe these interfaces in sufficient detail (for a problem statement draft)? - Are there any significant gaps or additional topics not present in the current document that should be? Richard Woundy asks who in the room has read the draft. About 40 people indicate they have read it. ** HUM TEST: Should we adopt the current problem statement draft as a WG draft? ** HUM RESULT: The participants agree to adopt the current draft. This will be confirmed on the mailing list. Presentation - CDNI Use Cases (First Presentation) Speaker: Gilles Bertrand Draft: draft-bertrand-cdni-use-cases-02 Materials: http://www.ietf.org/proceedings/81/slides/cdni-2.pptx Gilles explains that the current draft describes three categories of use cases: Footprint extension use cases, Offload use cases and CDN capability use cases. The goal of the draft is not to discuss technical solutions but to check whether the CDNI requirements meet the actual needs. The current draft is a merge of three other drafts: draft-bertrand-cdni-use-cases, draft-watson-cdni-use-cases and draft-ma-cdni-publisher-use-cases. Since the last version, the draft has been shortened and clarified. Furthermore, the terminology section has been cleaned up and the security section has been extended. Gilles briefly introduces the use cases making up the three different categories. For the footprint use cases these include: geographic extension, inter-affiliates interconnection, nomadic users and geo-blocking. For the overload use cases these include: overload handling and dimensioning, resiliency and branding considerations. The CDN Capability use cases consist of: vendor interoperability, CDNs with different features and QoE/QoS improvement. Jon Peterson asks whether there is a consideration for a use case describing awareness of content among interconnect CDNs. Gilles answers this is not within the current scope of the document. Gilles proposes to adopt the current draft as WG draft. Richard Woundy asks who in the room has read the draft. About 40 people indicate they have read it. Francois Le Faucheur suggests to first discuss the other use case draft before deciding on adoption of this draft. Presentation - CDNI Use Cases (Second Presentation) Speaker: Serge Manning Draft: draft-zhou-cdni-use-case-01 Materials: http://www.ietf.org/proceedings/81/slides/cdni-5.pptx Serge explains that the draft introduces four new types of use cases. He briefly introduces each of them. The first two cases are related to CDN service area and content authorization. The third use cases, which is also found in ETSI TS 102 990, discusses content adaption. The final use case, Content Priority, describes a scenario where certain content has priority over other content. As next steps, Serge mentions that the author has already mentioned that he will further clarify cases 1 and 2 and see whether they overlap with the cases presented in the Bertrand draft. Furthermore, the relevant requirements need to be extracted. Serge asks the room whether they think cases 3 and 4 make sense. Richard Woundy asks who in the room has read the draft. About 30 people indicate they have read it. *Discussion Ben Niven-Jenkins: Use case 3 sounds like transcoding, which we have already determined to be out of scope. Francois Le Faucheur: We will discuss this issue at the end of the WG session during open issues. Ben Niven Jenkins: I don't understand use case 4. Don't you mean that you want to mark content differently instead of delivering content differently? Serge Manning: I'm not sure, since I am not the author of the document. I would guess it has something to do with routing. Francois Le Faucheur: We will discuss this at the end of WG session. Philip Eardley: My proposal would be for the author to provide the delta from the other use case document. Kent Leung: We haven't accepted anything yet. We first have to decide what we want to add, before we add it to the other document. Francois Le Faucheur: Agree. We will try to make a list of the delta compared with the other draft and then see whether we can accept them. Richard Woundy: Do we wait for both documents to be ready before we take a hum test for adoption? Or do we want to decide on accepting the Bertrand document now? Eric Burger: I think it would be valuable to merge the two documents. I would like to see the merged document before deciding on acceptance. Ben Niven-Jenkins: I propose to first hum on the first use case document. Spencer Dawkins: If the first document is a WG document, we can all decide on whether the second document should be merged in. If it is an author document, the authors can decide. Richard Woundy: Ok, so we'll take a hum on the first document. Then, what the WG finds relevant in the Zhou document, we will merge with the then WG use case draft. Daryl Malas: Ok, but then all new use cases have to first be discussed on the list. Richard Woundy: Correct. (? Kim?): Why are we rushing for acceptance of if we are not sure what use cases to include? Richard Woundy: accepting it as a WG document does not mean that it is (almost) finished. We can still change it. We will do further revisions. Eric Burger: I like the idea of bringing it under WG control. However, since we already now that at least two other SDOs are looking at us. We have to make sure that they know that the document is not yet finished. Maybe include a some sort of caveat. Richard Woundy: I agree. We don't want to give them the idea that we're finished with the use case part. We will find some way to say that. Bruce Davie: I think we have had enough discussion on this, let's hum. ** HUM TEST: Should we adopt the Bertrand use case draft as a WG draft, with the caveat that it is not finished yet? ** HUM RESULT: The participants agree to adopt the Bertrand draft. This will be confirmed on the mailing list. Authors will include a clear statement that the draft is not yet finished and other use cases might still be included. Presentation - CDNI Requirements Speaker: Kent Leung/Yiu Lee Draft: draft-lefaucheur-cdni-requirements-02 Materials: http://www.ietf.org/proceedings/81/slides/cdni-1.pptx Kent mentions that the document has a new author: Kent Leung. In the future he will be co-editor with Yiu Lee. Kent explains that the requirement language in the document has been changed. It will no longer use RFC 2119 language. Instead it uses a new definition for (lower case) Must, Should and May, which are defined in the draft itself and describe the impact of various requirements on the WG schedule and deliverable timeline. The idea is that a Must requirement is essential for the WG. A Should requirement indicates that it needs to be done, but that the WG may, at a later stage, decide to re-evaluate this position. A May requirement indicates an optional requirement, with the lowest priority. Kent mentions that on the list there has been a discussion on the content acquisition interface. He will not discuss that now, but prefers to defer this discussion to the list. Kent discusses the following changes to the draft: - R37, suggested by Kevin Ma, has been added. This requirement allows an uCDN to avoid redirection to a dCDN if that makes the total redirection time exceed some limit. - R38 (old), R39 (new) has been changed to allow a uCDN to convey information pointing to CDN metadata to be applicable individually or through inheritance. - R58 (old), R59 (new) has been changed to allow for a CDN delegation whitelist/blacklist indicating which CDNs content may be delivered through. Jon Peterson mentions that using terms like 'beyond initial scope' and 'may' interchangeably is confusing, since they seem to be the same thing. Richard Woundy answers that they will change this so 'may' is used everywhere. Yiu Lee presents the proposed changes to the draft: - Change 'protocol' to 'interface' - Remove the 'beyond/within initial scope' and only use 'Must/Should/May' - Clean up duplicate requirements - Check requirements for inter-dependency. If one is implemented, then other should be too. * Discussion Wes George: Why are we redefining the terms must/should/may. That is just confusing. If you are going to use these words for other purposes, then you should not use RFC 2119 language. David Harrington: When this goes to the IESG, you will find that this will be a problem. Whether you use uppercase or lowercase it is still confusing. Just use different terms. Serge Manning; I agree. Must/may should not be used to indicate timelines. Eric Burger: This document seems to be a sort of micro-charter, just for internal use. Do not let the prioritization in this draft be leading for the work done. Yiu Lee continues with the proposed changes to the draft: - Change requirement numbering to include interface identifier (e.g. RR-xxx, MX-xxx, etc.) - Add generic requirement: no impact on CSP - Check whether to include ATIS requirements - Move definition of recursive/iterative RR to another draft (possibly the Framework draft) * Discussion Serge Manning: For the ATIS requirements, I know of some people who have already stated that they will try to look at them and see whether there is anything that should be added to this draft. Eric Burger: We do not have a formal liaison with ATIS, so for our purposes they are not ATIS requirements; just some IETF requirements we can decide whether to add or not. Jason Livingood: Can you please use a different abbreviation than MX for the requirements numbering? Maybe use MDX instead? Yiu Lee presents the open issues for the draft: - R8/R12: Clarify that cascading CDNs means more than 1 level of redirection - R14: Does uCDN need to be aware of virtualization? - R30: Clarify that simultaneous is not RR but content delivery - R31/32: Surrogate selection is not part of CDNI? - R35: Not clear about this. Why should CDNI RRI loop prevention allow routing a looped request? - R48/49: Should it be a Must for dynamic and preposition of distribution metadata? - Should we move security considerations to separate draft? * Discussion Richard Woundy: What exactly do you mean with the last item (moving security considerations)? Yiu Lee: We propose to only leave the high-level security requirements here, but move the overall security section to a seperate draft. Francois Le Faucheur: Let's leave the security-related requirements here and place the rest (i.e. security analysis) in the framework draft. Kent Leung: Does the security section include a threat analysis? Bruce Davie: The current charter says that we should place the threat analysis in the the framework draft. David Harrington: You might want to include the identification of threats in the requirement draft. The ways to mitigate those threats should be in a solution draft. Francois Le Faucheur: During the BoF we decided that the discussion of threats would be in the framework draft. David Harrington: Just a suggestion. Richard Woundy asks who in the room has read the draft. About 45 people indicate they have read it. ** HUM TEST: Should we adopt the current requirements draft as a WG draft? ** HUM RESULT: The participants agree to adopt the current draft. This will be confirmed on the mailing list. Presentation - CDNI Framework Speaker: Bruce Davie Draft: draft-davie-cdni-framework-00 Materials: http://www.ietf.org/proceedings/81/slides/cdni-6.pptx Bruce notes that this draft has a strong similarity to the cdni-strawman document (draft-peterson-cdni-strawman-01) since this draft incorporate parts of that document. He mentions that the other draft will remain as a sort of minimalist approach to CDNI interconnection. Bruce explains that the objective of this draft is to describe how all the pieces of CDNI fit together. This means that the draft will probably also include some informative examples of components that have been determined to be out-of-scope for CDNI, such as content acquisition, but that are necessary in order to deliver a full CNDI solution. Another goal of the draft is to illustrate some key design tradeoffs (e.g. HTTP versus DNS based redirection). The draft explicitly leaves the details of interface specification to other documents and that the draft is not meant to be descriptive. Finally, the draft also includes some CDNI deployment scenarios. Richard Woundy notes that you might also call this draft a solutions document or an architecture document. Richard Woundy asks who in the room has read the draft. About 40 people indicate they have read it. Bruce indicates the next steps for the draft: - Add interface definitions - More discussion on design tradeoffs - Draw conclusions from examples - More security considerations - Deal with mailing list comments - Say more about relationship to ALTO for choosing between multiple dCDN candidates - Get another round of discussion on list - Maybe next revision as candidate for WG? Spencer Dawkins mentions that he thinks that a lot of good work has been done in this draft. While he thinks that another revision would be good, he notes that it is definitely in the right direction. Francois Le Faucheur asks authors of similar documents to see whether they can identify from their drafts relevant deltas over draft-davie so they can be considered for incorporation in this I-D. Presentation - CDNI Request Routing Speaker: Spencer Dawkins Draft: draft-xiaoyan-cdni-requestrouting-01 Materials: http://www.ietf.org/proceedings/81/slides/cdni-0.ppt [This presentation did not occur during the working group session.] Presentation - Considerations on Request Routing for CDNI Speaker: Martin Stiemerling Draft: draft-stiemerling-cdni-routing-cons-00 Materials: http://www.ietf.org/proceedings/81/slides/cdni-4.pdf Martin explains that while there are multiple drafts in the area of request routing, he feels that some operation issues are missing from these drafts. He presents an example of a request routing process with some calculations on the number of round-trip-times that are necessary. He proceeds by giving an indication of average round-trip-times, resulting in a request routing delay of at least 180ms. Martin notes that this is quite long compared to other internet services and that in some cases, when speed matters, current RR schemes are probably too slow. He notes that faster alternatives are necessary. Other things that he would like to include in the draft are failure detections and operational recommendations. Francois Le Faucheur asks where Martin sees this document going. Martin answers that he would like to formulate some requirements for the requirements draft. Josh Gagliardi notes that the motivation for NSP to go for a CDN may be scalability through congestion avoidance. We may lose on latency, but with congestion avoidance you actually have a net gain. Presentation - Content Terminology in CDNI Speaker: Oskar van Deventer Draft: draft-deventer-cdni-content-terminology-01 Materials: http://www.ietf.org/proceedings/81/slides/cdni-8.pptx [This presentation did not occur during the working group session.] Presentation - Open Items Speaker: Francois Le Faucheur Materials: http://www.ietf.org/proceedings/81/slides/cdni-3.pdf (starting with slide 9) Francois describes the three main open issues for the WG at this moment: Content adaption, differentiated delivery and DECE/Ultra-violet. On content adaption (CA), Francois explains that while some content adaption mechanisms are clearly out of scope (such as how to perform CA), some aspects could potentially be relevant to this WG. As examples he mentions how a dCDN is made aware of a CSP's CA policy and how an uCDN is made aware of the CA capabilities of a dCDN. He asks the room whether the WG should include these kinds of aspects. * Discussion Wes George: I agree that how to do CA is out of scope. But some things may be in scope, such as request routing for adapted content. Some (parts of) CDNs might only handle specific types or versions of content. You might want to signal that. Josh Gagliardi: I strongly don't want. CA is currently moving too fast with too many vendors working on different proposals. Eric Burger: Some CSP don't want CA to ever be performed on their content. You might want to signal that. Serge Manning: Signalling should be ok. CDNs should be able to communicate policies. Ben Niven-Jenkins: I say no. It's a can of worms. We've got enough to do already. But I would be ok in making things flexible so it can possibly be added in the future. Kent Leung: I agree with Ben. Ramani Pandurangan: Transcoding and so on should be out, but the signaling of policies should be in. Francois Le Faucheur: Maybe we should make the policies a should. If we have time, we can do it, but if the timeline is a problem then we leave it. Ben Niven-Jenkins: The problem with that is that once you realize that, it's already too late. Kent Leung: Agree with Ben. I'd leave it as a May. Richard Woundy: Debate seems to focus on the second sub-bullet. We will take it to the list. On differentiated delivery, Francois explains that some CDNs may have different service layers (regular vs. premium). He notes that while some aspects definitely do not belong here (such as SLAs and how to realize), some aspects might be in scope, such as how a dCDN is made aware of uCDN policies. He asks the room whether the WG should include such aspects. * Discussion Eric Burger: Does anybody really care for this? Not just an academic exercise? Bruce Davie: This feels like a can of worms. Low priority. Ben Niven-Jenkins: Agree with Bruce. The impact of it is not clear for me. Serge Manning: I think we should have the signalling, but keep it very simple. We don't want people to go out-of-band to handle these things. Operators want assurances that things will work. Richard Woundy: Can you provide a use case? Serge Manning: ATIS references operators may be concerned about resources, so they want to know how critical content is relative to delivering it. Ben Niven-Jenkins: We have an existence proof: Layer 3 VPNs are a multi-billion dollar market today and they do all of this out of band. Francois Le Faucheur: I challenge that assertion. They do most of it out of band, but they still use an in-band signaling mechanism (DSCP) to invoke the differentiated services. Ben: OK, but the mapping of DSCP and its meaning is out of band. Francois Le Faucheur: yes, but that part, I am hoping we all agree is out of scope. Richard Woundy: We will take it to the list. On DECE/Ultra-violet, Francois invites people to think about the relevance of Ultra-violet to CDNI. He asks people to let him know if they can contribute on this. At 19:50, the chairs close the meeting.