CDNI WG Minutes IETF-115 London Chairs: Kevin Ma and Sanjay Mishra AD: Francesca Palombini Agenda and Slides: https://datatracker.ietf.org/meeting/115/session/cdni Recording: http://www.meetecho.com/ietf115/recordings#CDNI Chair Update: Sanjay and Kevin - Kevin: Footprint draft submitted to IESG - Kevin: Capacity insights draft adopted draft-ietf-cdni-interfaces-https-delegation-12: Frederic Fieau - Kevin's comments - Sanjay/Frederic: Kevin sent comments to the list, they will be addressed - Kevin: The draft is in good shape, we can try for WGLC before IETF 116 draft-ietf-cdni-https-delegation-subcerts-00: Guillaume Bichot - Guillaume: Kevin proposed removing FCI and only using MI doesn't support push - Guillaume: New proposal: FCI would only advertise max creds not actual creds needed - Guillaume: The uCDN, not the dCDN, should control when creds rotate, so it requries push - Nir Sopher: How does the uCDN push the creds? triggers? - Guillaume: SVTA supports triggers or a "simple configuration interface" REST interface - Nir: It allows removal - Guillaume: It allows removal and modification - Sanjay: It's a lot of the work for the uCDN. Should the dCDN be responsible for it? - Guillaume: It's a compromise. It requires a new interface, but FCI is not designed to support it. The uCDN needs to manage. The dCDN, if it needs creds, it will ask, and the uCDN will have to handle it. - Kevin: The dCDN can pull metadata at will, and the uCDN can used triggered pull, though they may not be preferred, why do they not work? Why is pulling metadata not enough? - Guillaume: One feature we'd like to propose is push for metadata - Kevin: Triggered pull is not good enough? - Guillaume: The uCDN having to wait for the dCDN to pull was viewed as problematic - Kevin: Even if push support was available (as part of CDNI or not) how does that affect the metadata definition in this draft? We should still be able to specify the data needed to support delegation separate from how it is transported, and it could support multiple transports. - Guillaume: Ok with that. Can have two methods to refresh the data. Just want to be able to support multiple methods of transport - Guillaume: Is the proposal to just advertise the maximum number of creds in FCI - Kevin: No problem with what's described, but want to see the draft. - Fred: Should this be aligned with the ACME STAR metadata object - Sanjay: It would be easier if this matched what the ACME STAR draft is doing. needs to be discussed on the list. - Kevin: It would be nice, but this draft needs an extra parameter (how many creds), not just an enable/disable on support for the metadata. - Guillaume: Agreed, it is different. We need the extra parameter draft-ietf-cdni-capacity-insights-extensions-00: Andrew Ryan & Ben Rosenblum - Andrew: The "scope" is intended to add more granularity to the footprint objects - Kevin: Footprints make sense, especially with footprint union. It would be nice if we could tie scope back directly to host metadata using a new footprint type (unioned with the existing footprint) - Andrew: For DNS request routing, DNS is the most granualar. For HTTP delegation, path could be taken into account. - Chris Lemmons: Second the use of footprint. There are many cases where the footprint isn't enough, but it's best effort and solves the problem more neatly than the previous proposal - Ben: Also like the footprint approach. - Alan Arolovitch: Is a footprint a set of network resources or user resources? It is ambiguous. - Andrew: It is measured by where the user is. - Kevin: CDNI is based off user, we don't want to expose CDN infrastructure. If a CDN says it serves a certain user area, we accept that as truth, and if users mascarade as being in a certain area, we accept that as truth as well. - Andrew: The dCDN advertises a best guess, it is not an SLA - Chris: I think we all agree business arrangements (penalties, SLAs, etc.) are out of scope - Andrew: Agreed. No SLAs or reservations. Happy path, best case, advertisement. - Anant Sshah: Is the advertisement ingress or egress capacity? - Andrew: It is how much capacity (to the users) the dCDN is allowing the uCDN to delegate - Anant: So it doesn't consider ingress? - Andrew: This does not consider dCDN ingress/uplink from the uCDN origin. - Ben: Could add a new use case and limit for ingress - Ben: Note: the uCDN can see what is leaving its caches but cannot see what is leaving the dCDNs caches, so the telemetry gives insight into the latter draft-ietf-cdni-ci-triggers-rfc8007bis-01: Nir Sopher/Sanjay Mishra - Alan: Can this support custom attributes - Alan: e.g., preposition can get hairy with rules like: only use resources X at time Y - Nir: That was an original motivation for this draft, to add extensibility to triggers. Would value feedback - Alan: I was thinking extend the trigger payload with custom attributes, but you are describing a different dimension of how do you run triggers, e.g., repeatedly or at a certain time. - Nir: Both are actually already in the draft - Sanjay: Let's continue the discussion on the list - Nir: Doing a clean read of the draft and intend to have an update for IETF 116 CTA WAVE streaming media tracing: Chris Lemmons - Chris: Goal: to pass forensic metadata along with content from source (camera/mic) through processing (transcoder) and CDNs to client - Chris: Working on Pull stage: HTTP request and response headers to represent a graph of the trace, including unsuccessful flows (WIP) - existing solutions only show the successful path - Chris: How does it affect CDNI: Eventually there may be configurations that we want to distribute through CDNI - Sanjay: Please send questions to the list Request Routing Interface: Alan Arolovitch - Alan: Recursive request routing is needed to reduce latency and give uCDNs more control of the content (e.g., ad insertion, session admission) - Alan: Rather than encoding parameters, pass actual HTTP requests from uCDN to dCDN and actual HTTP responses from dCDN to uCDN to be sent back to user - Alan: Request Mode: uCDN forwards request to dCDN - Alan: Response Mode: uCDN forwards response to dCDN - Alan: New draft coming for IETF 116