Skip to main content

Minutes IETF115: cdni

Meeting Minutes Content Delivery Networks Interconnection (cdni) WG
Date and time 2022-11-11 12:00
Title Minutes IETF115: cdni
State Active
Other versions plain text
Last updated 2022-11-30

CDNI WG Minutes
IETF-115 London
Chairs: Kevin Ma and Sanjay Mishra
AD: Francesca Palombini

Agenda and Slides:

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