CDNI BoF IETF-80, Prague, Czech Republic Thursday 31 March 2011, 17:40-19:40 Hilton Prague, conference room Barcelona/Berlin Chairs: Francois Le Faucheur     Richard Woundy  Draft Minutes: Emile Stephan, edited by Francois and Richard (last edited April 6 2011) Chairs open the meeting at 17:40.  They point out the CDNI web links and identify the note takers. Chairs present the agenda (4 parts: problem statement, scope for the ietf, charter, and wrap up). See "agenda" under https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni. Chairs recall the objectives of a BoF. See "BoF Introduction" presentation under https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni. They recap what is CDNI about: allow CDNs to interoperate while today they only operate in silos and don't interoperate. Audience of about 120 people. * Part 1: What is the Problem we are trying to solve?  =================================================== ** Nabil Bitar (Verizon) presents the first part of draft-jenkins-cdni-problem-statement: the problem space and drivers See "Problem Space" presentation under https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni. +Intra CDN and inter CDN - Intra CDN goal leverage assets: result of many situations: mergers/acquisitions; multi vendor deployments - Inter CDN: interconnection between CDN managed by different providers; Alternative to expand existing CDN; value proposition for CSP; Optimize network consumption +Key missing enablers -  Exchange information needed for interconnect -  Request action from one of the interconnected CDNs -  Exchange information to optimize request routing -  Report request routing rejection -  Communicate CD policies -  Report accounting and events   + ?: CDNI only talks about interconnecting two CDNs, but is "CDN Federation" in scope? + Nabil: CDNI is about interconnection only. Federation is a more controlled environment which requires more policies. + Francois: CDNI only defines how to interconnect two CDNs together. This can then be used in different ways, such as allow many CDNs to interconnect to many CDNs. But the notion of "CDN Federation" itself is not in the scope.   ** use cases draft-bertrand-cdni-use-cases See "Use cases" presentation under https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni. Gilles bertrand (from Orange) presents the use cases of the I-D draft-bertrand-cdni-use-cases +Overview: merged 2 drafts of use cases (one driven by FT and one by BT). Real world use cases. Does not discuss any technical solution +footprint extension: Geographic: applicable to ISP and OTT Region to region: e.g. inter TELCO +Nomadic usage: +Content distribution restriction: propagate information +The figure in slide 4 illustrates CDN footprint extension between 2 CDNs where the CP is connected to the first CDN and the viewer is connected to the second CDN. +offload: Interconnect to increase capabilities (e.g. special event) +Resiliency: cover partial failure +CDN capabilities: CDNs with different features peer to satisfy CP feature requirements. +Vendor interoperability +Proximity improvement: e.g. OTT use ISP surrogate + Gilles highlights that the use cases are applicable to any combination of types of CDN (i.e. ISP or OTT). + Gilles concludes that he presented real world and highly desirable use cases and that the next step was to merge with draft-ma-cdni-publisher-use-cases Question & Discussion: + Aaron Falk, Clarification: in the slide #6,  what does "surrogate" mean? + Francois: it stands for "cache". + ? (from Huawei): what is the interest for ISP for caching content in other service providers?  + Yiu Lee: they want to deliver closer to the customer, and there are a lot of streams. + Francois encourages the person to read the cdni-use-cases I-D as it precisely discusses why SPs want to use each others's CDN. ** Publisher use cases See "Publisher use cases" presentation under https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni.  Kevin J. Ma (Azuki Systems) presents the I-D draft-ma-cdni-publisher-use-cases. Kevin presents use cases relevant for publisher (a publisher makes money in distributing content often over several CDNs). The use cases are: +supporting multiple device resolutions (eg high definition and low res) +split subscription: fixed and mobile +HAS: highly segmented video supports adpative bitrate streaming +Live streaming time based component +distribution policies management: "who is allowed to watch which content when?" Need to update the policies +Next Step: - incorporate into Gilles use cases draft - Geo blocking - Session shifting - Resiliency: fail over In conclusion Kevin proposes: * several enhancement to cdni-use-cases * several enhancements to cdni-requirements Question: none ** ATIS use cases See "ATIS use cases" presentation under https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni.   Bruce Thompson (Cisco) presents the ATIS scenario. He recalls ATIS rule and importance. He recalls that ATIS prefers reusing protocols when available, rather than invent. + ATIS COD 0800042 is built on ATIS, ITU 3GPP & IETF spec   - 2 use cases: Off net delivery and internet source content   - Offnet delivery: ATIS use case matches the current CDNI problem statement and CDNI requirements   - Internet source content:  + In one flavor: ATIS use case matches the current CDNI problem statement and CDNI requirements + In another flavor, looking for extensions: control over the path by the ISP acting as a service provider: match the current CDNI problem statement but adds extra requirements. Question: none ** Experiments See "Experiments" presentation under https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni.    Larry Peterson (Verivue) presents the I-D draft-bertrand-cdni-experiments. It depicts a trial of CDNs interworking between France (Orange) and Poland (PT) between a Cisco CDN and a Verivue/Coblitz CDN. +simple: aim to prove feasibility of basic content exchange and discover what we don't know +request routing: call flow: use of HTTP and DNS; URL embeds all the information of the content; No new protocol. +loop avoidance added; +lessons: feasibility demonstrated with minimal metadata and maximal opaqueness Many feature not yet explored (e.g. purge) A number of assumptions made and systems configured in lieu of standards. Question: none HUM TEST: Francois restates that subsequent agenda parts will discuss the problem space that the working group should take on, and details of charter and deliverables. For now, we just want to gauge the room about whether there is a useful problem to solve. Francois asks for vote by humming: + Do you think we have a real problem that needs solving? 60 + Do you think we do not have a real problem that needs solving? 2   * Part 2: What subset of the problem should IETF take on? (40 min) ==================================================== ** scope/priorities/what-can-be-reused/standards gap See "Scope and priorities" presentation under https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni. Ben Niven-Jenkins (from Velocix) presents the 2nd half of draft-jenkins-cdni-problem-statement. He recalls the reference model 4 interfaces +Control to enable 1 CDN to affect the state of another (purge…) +Logging interface: defined the info to log; What is going on +request routing; +Metadata: CDNI can be seen as an information exchange problem. Does not need new "protocol" per say. +Non Goal, Out of the scope : - Between CDN and CSP, between CDN and end user - Encoding, DRM, - apps consuming CDNI Logs: the work is about transferring log - Internal CDN aspects like scalability; algo for req routing, cache selection, +Priorities: - Industry need a solution in a limited time frame: 18-24 months; - Hence the charter encapsulated the minimal things needed to operate an interconnection - Enhanced scope would need recharter - reuse not reinvent +standard Gap: ATIS and ETSI are working on interconnection CDN and don't want to develop their own protocols and instead can reuse CDNI. Discussion: + Yunfei (China mobile): is it appropriate for a CDN to purge content in another CDN? + Ben: Yes, when Content Provider wants the content to be removed from all caches (in all CDNs). + Yunfei gives an example of potential privacy leaks with CDNI. The big concern on logging and accounting is that it may involves information that can create privacy issues. Suggests carefully design the logging. + Ben: Not much more information regarding privacy than in existing single CDN model of today. + Rich: the WG will have to consider and address this privacy issue. + Jason: every IETF document has a security section and it could be covered there. + Spencer Dawkins (?): this has to be handled when the WG is set up + Eric Burger: need to take care of the new problem of transitive trust origin of the info. + Rich proposes to add the privacy concerns to the charter. + Lucy (Huawei): interfaces not clear with respect to the content distribution + Ben & Rich: out of the scope, already defined + Francois: the control plane to enable distribution (eg convey content source in metadata) is part of CDNI but the actual acquisition is not. + ?: how does that relate to DECE/UltraViolet? + Ben: should be orthogonal as happens "on top of" CDNs + Eric Burger: We should identify the requirements that UltraViolet may place on CDNI. + Jon Peterson (IAB and UltraViolet hat also) : UltraViolet may be relevant (eg they also define metadata). UltraViolet folks are aware of this new CDNI activity. + Spencer Dawkins (IAB): it would be smart to have discussions with these people (for the final charter) + Francois asked for contacts in UltraViolet community to establish discussions + Dong Wang (ZTE) asks for content modification to adapt. + Ben: if not available to distribute then rejected ** Requirements Yiu Lee (Comcast) presents the draft draft-lefaucheur-cdni-requirements See "Requirements" presentation under https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni.  It is a proposed list of requirements to target in the initial charter and future scope. +generic: leverage existing protocols; don't touch to end user nor the CDN; HTTP for delivery and acquisition; any CDNI topology; prevent looping +control: bootstrapping and purge +request routing: allow uCDN to delegate and the dCDN to refuse; advertise policies; support small and large object; pass user agent location information; + Yunfei: why mention HTTP and DNS since the interface between user and Request-Routing is out of scope (ie CDNI Request Routing interface is across CDNs)? + Francois: It is useful to mention these two as it actually affects the CDNI Request Routing interface (eg because HTTP-based redirect and DNS-based redirect will not provide the same information to be conveyed across CDNs - eg IP address of end user vs IP address of DNS Proxy). + Wang (ZTE): we use FTP for acquisition from different content providers. + Bruce Davie: acquisition is out-of-scope. So FTP is allowed on this interface. + Anton Ivanov : There are implicit requirements on metadata on uses. "I would not like to give my data logs to someone else". ?Anton Antonov: metadata for content; metadata for user should be explicit for security and privacy. + Stephen Farrel: you mention "non-repudiation" but that requires things like time-based signature etc; that may be too heavy. ** CDNI Workscope recap. See "Workscope recap" presentation under https://datatracker.ietf.org/meeting/80/materials.html#wg-cdni. Francois presents: * a day in the life of CDNI * example candidate protocol stack: - control interface: - req routing interface : + ( or ) - logging interface : ; maybe also add IPFIX, DIAMETER, others - metadata exchange interface: : needs cachability ** Discussion before the hum test + Spencer: did you mention a couple of protocols that may need to be extended? + Francois: only need to define a schema, but no new schema languages and no new protocol or protocol extensions; + Ben: no new schema languages and no new protocol or protocol extensions needed. + ?: but there was mention of potential ALTO extensions? Does this need to be brought up in the charter? + Spencer: no need to do that in the charter + Eric & Spencer: charter to do this without extending existing protocols + Francois: we say that we need only to define several schema. If we need ALTO extensions this still only requires work on schema and not definition of new protocol or protocol extensions per say (whether done in CDNI WG or in ALTO WG). + Bruce Davie: it is pretty clear that CDNI does not require protocol work (ie only schema definition). + Spencer: ok to define a protocol at schema level: are you going to need the extension of protocol that another WG is in charge of? + ? : potential extra work for ALTO need not be decided/spelled out in the charter. + Haibin: will you define a fixed set of fields for the CDNI log? + Francois: There would be a minimum set of mandatory fields to support, plus perhaps additional optional ones. + Lucy: back to slide 5: how downstream CDN gets the content? + Rich: this is covered. let's move to general question + Haibin: can we have a similar standard between CP and uCDN? + François: such standards already exists (eg see CableLabs). CSP to upstream CDN is out of scope for CDNI. + Jon Peterson: lot of expertise required when presenting this to the IESG : BGP expertise, logging expertise, URI expertise (scheme extensibility)… + François: we showed multiple candidate protocol stacks, but we are going to pick only some of those, we will not need them all (eg BGP would only be needed instead of ALTO, and it may be that neither of these two is needed to address initial charter). + Ben: HTTP will probably mainly be used. + Ben: contributors have developed and experimented with potential CDNI; they have expertise covering the needed spectrum. ** HUM TESTS François indicated we now want to assess whether the problem statement is well defined and appropriate for IETF. + Do you think the scope of the problem is well defined and understood? 60 + Do you think the scope of the problem is not well defined and understood? 0 + Do you think the IETF is the right place to solve that problem? 70 + Do you think the IETF is not the right place to solve that problem? 0 * Part 3: Potential Charter ===================== François reads the draft charter; (Rich edits the draft charter to reflect input/discussion) ?: The CDNI threat model needs to be defined + Rich added a note in charter to cover "CDNI threat analysis" + David H: let's focus on the list of deliverables + Anton : trust Model must be discussed; + David H: if you are going to document "threat analysis", you will need to discuss "trust model" + Rich: add mention of trust model and privacy along with threat analysis in edited charter. + David H: No explicit mention of DRM? + Francois: it is listed as out of scope in problem statement, and we should also state that in the charter. ** HUM TESTS + Do you feel that the Charter lists the right set of deliverables? 60 + Do you feel that the Charter does not list the right documents? 0 + Do you feel that a WG should be created with this charter? 60 + Do you feel that a WG should not be created with this charter? 0 ** SHOW OF HANDS for contributors + Raise your hand if you are ready the edit documents of the WG ? 25 + Raise your hand if you are ready to review the documents of this WG ? 35 Meeting closed at 19:44 by Dave Harrington.