CDNI WG Minutes =============== Meeting: IETF-82, Wednesday, November 16, 2011, 0900-1130, Location: Room 101C, TICC, Taipei, Taiwan Chairs: Francois Le Faucheur, Richard Woundy Minutes: taken by Vinayak Hegde, edited by Francois Le Faucheur Attendance: ? (don't have blue sheet numbers yet) [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/ietf82/ietf82-101c-20111116-0855-am.mp3, starting at offset 00:06:00 and completing at offset 02:34:20.] Tentative Agenda: * Agenda bashing & Introduction: Chairs (5 mins) * Discussion on scope & interface split: Chairs (10 mins) * Problem Statement, draft-ietf-cdni-problem-statement-01: Ben Jenkins (10 mins) * Use Cases, draft-ietf-cdni-use-cases-00: Giles Bertrand (10 mins) * Advanced Use Cases, draft-fmn-cdni-advanced-use-cases-00: Jan Seedorf (5 mins) * Requirements, draft-ietf-cdni-requirements-01: Kent Leung (10 mins) * Additional Requirements for ATIS CSF, draft-manning-cdni-additional-csf-reqs-00: Serge Manning (10 mins) * Framework, draft-davie-cdni-framework-01: Aaron Falk (15 mins) * ALTO for CDNI Request Routing, draft-seedorf-alto-for-cdni-00: Jan Seedorf (10 mins) * CDNI Footprint Advertisement, draft-previdi-cdni-footprint-advertisement-00: Stefano Previdi (10 mins) * Request Routing Protocol for CDNI, draft-xiaoyan-cdni-request-routing-protocol-00: Xiaoyan He (10 mins) * CDNI Core Metadata, draft-caulfield-cdni-metadata-core-00: Kent Leung (10 mins) * CDNI Interconnect Metadata, draft-jenkins-cdni-metadata-00: Ben Jenkins (10 mins) * CDNI Metadata Interface, draft-ma-cdni-metadata-00: Kevin Ma (10 mins) * Metadata for CDNI, draft-stephan-cdni-usecases-metadata-00: Emile Stephan (10 mins) * Conclusion and next steps" Chairs (5 mins) ========== 1. Agenda bashing & Introduction: Chairs/Rich (5 mins) --------------------------------------------------- Refresher on Milestones Agenda overview: * Foundational documents: Problem statements Use cases Requirements Framework * protocol documents Request Routing interface Metadata Interface no request to change the agenda. 2. Discussion on scope & interface split: Chairs/Francois (10 mins) ------------------------------------------------------------------- See Chairs slidedeck. Request routing comprises 2 parts 1. asynchronous operations - advertisement of CDN footprint and capabilities 2. synchronous operations of redirection of user request. We recommend this be noted by the WG and the following terminology be used: 1. "Request Routing Interface/Footprint & Capabilities advertisement" 2. "Request Routing Interface/Redirection" We note that these two components of the Request Routing Interface may be based on different protocols, and may be progressed in separate documents at different pace. The distribution of functionalities across the individual CDNI interfaces is not quite finalized and a subset of it may move (eg "triggers" under Control Interface vs Metadata Interface). This need not hold back progress of the Problem Statement since it already mentions that the final distribution may evolve. Content adaptation can be achieved via 3 main approaches: Approach A. Content adaptation is done by CSP Approach B. Content Adaptation is done by uCDN Approach C. Content Adaptation done by dCDN in a managed way CDNI already allows Approach A and approach B without further work. Option 1 -> Support A & B but not C (leave C for CDNIv2) Option 2 -> Support A & B, support C in unmanaged way (leave C for CDNIv2) Option 3 -> Support A & B & C in a managed way Yiu Lee : Do we have estimates on impact of each option on the timeline for completion of the work ? Rich: The expectation is that as you go from option 1 to option 2 to option 3 it will require greater work. David Mc Dyson : Would "CDNIv2" require rechartering of the group ? Rich & Francois: Yes, CDNIv2 means "beyond initial scope" and will require rechartering of the group Eric burger - Would anyone in the world actually do 3 ? Hum test. Option 1 - Strong hum Option 2 - weak Hum + 2 hums from jabber. option 3 - silence The tentative agreement is to go for Option 1. This will be validated on the list. 3. Problem Statement, draft-ietf-cdni-problem-statement-01: Ben Jenkins (10 mins) --------------------------------------------------------------------------------- See Ben's slidedeck. Open question on grouping of functionality. There is already a note that Francois read out. Proposal is to leave the note and go ahead. If someone wants to make suggestions to enhance the note, that is fine. Document is ready to go to WG Last Call. Rich: Clarification question: we may not be 100% decided on the split of functionalities across interfaces, but we are clear on the actual list of functionalities, right? Ben: yes. David Harrington: is the intention of the WG to decide on the distribution of functionality? WG chairs: the distribution of functionality across CDNI interfaces will definitely be specified. And only a small subset is still to be decided. Rich: Question to Dave Harrington. Do you expect that the note in the Problem Statement about potential change of functionality distribution across interfaces may be an issue at AD review time? Dave: No. Lots of people have read the problem statement. Hum - is draft for last call ? Strong hum for yes. The tentative decision is to submit draft-ietf-cdni-problem-statement-01 to WG Last Call. This will be validated on the list first. 4. Use Cases, draft-ietf-cdni-use-cases-00: Giles Bertrand (10 mins) -------------------------------------------------------------------- See Giles' slidedeck. Need to reflect the decision about Content Adaptation (ie remove associated text). Need to move some text that belongs more to the requirements document. Next Steps: * issue new version * go for WG Last call in Jan 2012 Francois: When the new version comes out, please review it and comment. Then the chairs will poll the list about issuing the WG Last Call on that new version (without waiting for next physical meeting of IETF). 5. Advanced Use Cases, draft-fmn-cdni-advanced-use-cases-00: Jan Seedorf (5 mins) --------------------------------------------------------------------------------- See Jan's slidedeck. Goal is to document future use cases that are beyond the current charter. Next Steps: * get feedback, rev up * maintain separate from cndi-usecases, as catalogue of future work. 6. Requirements, draft-ietf-cdni-requirements-01: Kent Leung (10 mins) ---------------------------------------------------------------------- See Kens' slidedeck. People need to give feedback on the requirements so authors do not make assumptions. 7. Additional Requirements for ATIS CSF, draft-manning-cdni-additional-csf-reqs-00: Serge Manning (10 mins) ----------------------------------------------------------------------------------------------------------- See Serge's slidedeck. The CSF group under ATIS is working on usecases and requirements for CDNI. They rely on IETF to do protocol work. Objective is to incorporate in cdni-requirements, No feedback yet, please review and comment. Show of hand: about 10 read the document. WG-chairs: request people to read the draft, and comment, so that the requirements can be evaluated for incorporation in the requirements drafts. Orit Levin: I participate in this CSF group. These requirements have been developed by many companies most of them service providers so they should be accepted. Francois - Get people interested and get them to comment to say yes or no, and as usual to explain why Yes or No. Rich - note that if this group was to push back on a given requirement, this may be because of timing or scope issue, not necessarily because the requirement is not valid. 8. Framework, draft-davie-cdni-framework-01: Aaron Falk (15 mins) ----------------------------------------------------------------- See Aaron's slidedeck. Next Steps: * address the open issues just listed * we think it is ready to be adopted as a WG document. Francois : There is confusion about how the CDNI mesh will deal with adaptive streaming. there is agreement that it needs to be supported, but there are different views about how involved is CDNI in adaptive streaming. The 3 dimensions of interactions that come to mind are: * Logging which needs to be optimized for adaptive stream segment. * Request-Routing, which should not take place for every segment * Acquisition: segment based or content based. Would you agree to discuss this question in framework. Aaron: this is an excellent idea and is a great fit for the framework. We should discuss design options and associated trade-off. Francois : Does the document already sufficiently discuss use of metadata for request routing? Aaron: yes. Rich : show of hand: 20 people have read the draft. Hum tees to adopt Framework draft as WG document. Yes: Strong hum No: silence. The tentative decision is to adopt draft-davie-cdni-framework-01 as WG document. This will be validated on the list. Aaron Falk - Triggers belong to the Metadata interface and not the control interface. Triggers should go along with the data on which they perform action (eg a Metadata Purge trigger bellows in the Metadata Interface) Ben Niven Jenkins - I have completely opposite view. My proposal is that people document proposals and we settle it like that. Francois: Some of that discussion relates simply to how we "call" the interface, but that does not affect the actual protocol to realize the Triggers. The rest of the discussion has to do with whether the triggers can leverage some protocol components of the Control Interface or Metadata Interface, and that impacts the protocol to realize the Triggers. Aaron: We should not wrap-up Triggers with these like Bootstrapping. Ben: we agree on that. 9. ALTO for CDNI Request Routing, draft-seedorf-alto-for-cdni-00: Jan Seedorf (10 mins) --------------------------------------------------------------------------------------- See Jan's slidedeck. Jan: so, can ALTO be beneficial to CDNi ? Francois (as Individual): Can ALTO be beneficial to CDNi ? At this stage, it seems that in principle ALTO "could" potentially be useful, but we don't know how, and I am not sure it can be that useful because: 1. you discuss how ALTO could provide some info to help uCDN select dCDN Surrogate. However, the uCDN needs other info that ALTO could not provide, and likely very hard to get so I don't believe dCDN Surrogate selection by uCDN is really possible in general. 2. you mention ALTO could help uCDN to select dCDN, which is a problem we want to solve, but you don't discuss how. ???: why can the "other" information needed by uCDN to select dCDN Surrogate not be passed in ALTO Francois: one example is that the dCDN may want to select a Surrogate depending on the content that is served. So ALTO would need to provide info that depends on the content and uCDN know how to use it. Richard Alimi: to Francois' comment on confidentiality. ALTO can take into account metrics without actually revealing them, and can take into account multiple metrics. If you need additional info, it would be useful to feed that info into ALTO WG. Jon Peterson: I agree ALTO may not be able to provide all the needed info, but maybe you don't want to restrict to a single source of info. Do you want to restrict to a single source of info for request-routing? Francois: There are two problems. One problem is to help uCDN select a dCDN. This is a clear problem, and ALTO could potentially address that problem but there is no information on how to do that in the draft. The other problem is to help the uCDN select a Surrogate in dCDN. The draft discusses how ALTO can address part of that problem but this is not a problem the WG has been going after. Jon: I agree, and perhaps Jan got it backwards and my recommendation is that he focuses on beefing up the use of ALTO for dCDN selection first, and later expand on how ALTO could also help for Surrogate selection. Also, maybe ALTO does not fit squarely under the "Footprint Advertisement" interface because it is not really "advertising". Francois: I think ALTO would actually fit nicely under the interface, it is just that the interface name would no longer suit. Jon: that's fair. Francois: I agree ALTO could be used to address the problem of dCDN Selection, but we need to consider the aspects of scalability and dynamicity and compare how the various proposals fare against that. Jon: Is your intention to come out with one single solution? Francois: Yes Jon: Why is that necessary? Rich: it is useful to be able to define a minimum for interoperability across CDNs so it is useful to define at least one protocol that both CDNs support. Jon: I see more a model where there can be different sources of information (eg ALTO and BGP), so I would not necessarily commit at this stage to define only one possible approach. Rich: That's fair Susan: I share Francois' view that the uCDN can not perform the dCDN surrogate selection. For the second part (ie how ALTO can help dCDN selection), I am waiting to see a specific proposal. Jan: I agree that I need to specify how ALTO can help dCDN selection. Regarding surrogate selection, ALTO would not be the exclusive source of information. 10. CDNI Footprint Advertisement, draft-previdi-cdni-footprint-advertisement-00: Stefano Previdi (10 mins) ---------------------------------------------------------------------------------------------------------- See Stefano's slidedeck. Martin Stiemerling: BGP has issues since prefixes can be incorrectly advertised to backhole traffic and there has been a few occurrences of that (e.g. by a Pakistan ISP). Stefano: that is a valid point that applies to any solution (BGP or ALTO or something else). e.g. if you use ALTO, a CDN can advertise a prefix but how can the CDN prove it can actually reach that prefix. Martin: that is a big problem for CDNI request routing. Stefano: The issue exist, but it is not necessarily such a big issue. It just needs to be looked at regardless of the proposal. Toerless Eckert: the previdi-cdni solution comprises two elements. One element is to compress the prefixes by referring to AS. That seems nice regardless of whether the protocol is BGP or something else. Regarding use of a new Address Family, I am not sure that the BGP operators would be willing to advertise that and needed attributes. Stefano: That's not the idea. We might even need a new Address Family. The key point is that we don't want to interfere with existing BGP. Toerless: since the regular BGP is probably not the right vehicle to advertise CDNI policy, you could use a separate BGP overlay, like done with other applications already. Stefano: Indeed. Dave Mc Dyson: interesting approach, but if you aggregate at AS level, you lose granularity, so there is a need for finer grain. Stefano: Yes, we are working on this and will be in next version. The idea is to leverage communities to refine. Richard Alimi: one datapoint regarding encoding that. We did measurement on an ALTO implementation and we can encode the Internet table in 5 MByte and 10 Mbytes. Also, ALTO is now working on incremental updates, Stefano: That is good. Incremental updates are available for free in BGP. Susan: I don't quite see why you use BGP because we have other interfaces like the request-routing that could perhaps be used to advertise the information. Stefano: well BGP has all the right properties such as incremental updates, scalability,.. Jon Peterson: a Suggestion to help decide among approaches: first define the core semantics needed and then we can assess how the proposals support that. Rich: that's fair. Eric burger - Regarding blackholing, can RPKI help with that? Jon: RPKI will not make BGP a better proposal. 11. Request Routing Protocol for CDNI, draft-xiaoyan-cdni-request-routing-protocol-00: Xiaoyan He (10 mins) ---------------------------------------------------------------------------------------------------------- See Susan's slidedeck. Francois: here is a suggestion. This document covers both the "Footprint & capabilities Advertisement" and the "Redirection" parts of the Request Routing interfaces. It seems converging on an approach for the "Footprint & capabilities Advertisement" may take some time to the WG, so I suggest you separate the two parts into two documents. This will allow the two to progress at their own pace and will make it easier for people to review. Susan: OK, I will. 12. CDNI Core Metadata, draft-caulfield-cdni-metadata-core-00: Kent Leung (10 mins) ----------------------------------------------------------------------------------- See Kent's slidedeck. Francois: We'll keep all metadata questions and discussion to after all metadata presentations. 13. CDNI Interconnect Metadata, draft-jenkins-cdni-metadata-00: Ben Jenkins (10 mins) ------------------------------------------------------------------------------------- See Ben's slidedeck. 14. CDNI Metadata Interface, draft-ma-cdni-metadata-00: Kevin Ma (10 mins) ------------------------------------------------------------------------------------- See Kevin's slidedeck. 15. Metadata for CDNI, draft-stephan-cdni-usecases-metadata-00: Emile Stephan (10 mins) ------------------------------------------------------------------------------------- See Emile's slidedeck. Ben Jenkins : It is not about "Push" or "Pull". It is about allowing metadata to be obtained ahead of it being needed. Francois: Right. Another way to say that is that we have discussed both a "triggered pull" or a "push" and they achieve the same functionality of having metadata obtained ahead of it being needed. So we could use either. Aaron Falk: a suggestion for an approach is to focus on mechanisms (eg pull, triggered pull) and scoping and coarse description of the content and not the syntax. To converge, it will be easier to talk on the concepts. Francois: on the positive side, the metadata proposals will be easier to converge (that the previous discussion on request routing) because they are mostly going in the same direction and there has already been a lot of discussions among authors. David Harrington : The Network management research group developed RFC 3444 that details difference between Information Models and Data Models. It would be helpful that this group aligns to these concepts as the IESG is mostly thinking along those lines. Conclusions and Next steps: --------------------------- 1. Problem Statement: (tentatively) will go to WG Last Call 2. Use-cases: new rev to be posted in Dec, will decide to go to WG Last Call on the list then 3. Framework: (tentatively) adopted as WG document 4. Metadata: good discussions this week. Not specific plans but expect to naturally converge 5. Request Routing interface - Footprint & Capability: * likely that authors of respective proposal update their proposal. * to document the core semantics needed (either as an I-D or simply documented on the list): volunteers (Jon, Martin), nominated volunteer (Stefano) 6. Request Routing proposal - Redirection: Susan will document her proposal in a standalone document. 7. Remaining CDNI interfaces (logging, Control, Triggers): Chairs encourage proposals on these topics.