Re: [CDNi] Request for WG Adoption: CDNI Metadata Model Extensions

[Kevin Ma <[e-mail]>]

Hi Alfonso,

  I think there is a lot of good work in the draft.  I'll reiterate
though that the draft is a bit dense, and I think it would benefit from
being split up at least into a set of non/less controversial metadata that
could easily be reviewed and approved (similar to the work on request
routing and footprints) and the more intricate processing stage content
(which I personally think is interesting and a good addition and callout on
the original metadata model, but will likely take more iteration to
converge).

thanx!

--  Kevin J. Ma

On Thu, Mar 24, 2022 at 4:42 AM ALFONSO SILONIZ SANDINO <
[e-mail]> wrote:

> Hi All,
>
>
>
> Following the discussion during IETF 113 meeting, after the changes made
> to the draft attending different comments after IETF 112 meeting, I would
> like to ask for the group to make this draft an adopted CDNi WG document.
>
>
>
> The latest version of the draft can be found here
> <https://datatracker.ietf.org/doc/draft-goldstein-cdni-metadata-model-extensions/>
>
>
>
> About Kevin suggestion of breaking out this draft on smaller parts I think
> is a very fair point that we will discuss with our colleagues in the SVA
> Open Caching WG, as we want to maintain alignment in the OC documentation
> with the drafts presented to CDN-I for easier referencing.
>
>
>
> As for Sanjay suggestion, I add here the list of comments to the previous
> version  and our responses that were in our slidedeck for the meeting but
> for the sake of time was not possible to present in detail.
>
>
>
> Please, let us know if you agree or disagree with this adoption. And feel
> free to make any additional comment.
>
>
>
> Best Regards,
>
>
>
> Alfonso Siloniz
>
>
>
>
>
> *draft v01*
>
> *draft v02*
>
> *Question*
>
> 2.2
>
> 2.3.2
>
> add cross reference for HeaderTransform
>
> Missing in v2. Set for v3
>
> 2.2
>
> 2.3.2
>
> MI.AllowCompress: Without this metadata today, a dCDN is free to choose to
> compress? t feels more natural to make the default true or change the
> metadata to DisallowCompress?  Otherwise, without an FCI advertisement of
> whether the dCDN supports the metadata, it's hard to know what its default
> behavior will be?
>
> Without it, there is no enforcement from the uCDN about dCDN behavior for
> compression. The purpouse of the functionality is to force compression in
> dCDN independently of how the uCDN content has been acquired. Agreed
> probably the name does not reflect precisely the functionality, and
> something like EdgeCompress or ForceCompress would be more suitable. In
> discussion in the SVA OCWG
>
> 2.3
>
> 2.1.1
>
> I'm curious about the use case.  The uCDN could just set the desired cache
> policy in the response, rather than setting the metadata.  Is the primary
> use case where the uCDN does not want to set the cache policy in each
> response and wants a default in the metadata?  Or is there something else?
> Is it to have a push interface (note: the triggers API provides a way to
> invalidate)?
>
> Cache Control directives condition how any cache system in the path
> between the uCDN origin and the user agent should behave. As the uCDN can
> only use one specific Cache-Control header, it has no flexibility to
> control the TTL of the objects in a dCDN cache. It would be the same for
> the dCDN cache and for an intermediate cache system.
>
> As the uCDN can have control over the objects the dCDN stores (as with the
> trigger interface mentioned) it can be of the uCDN interest to have a
> longer TTL for the dCDN Caches (so there is less traffic to the uCDN
> origins) but having a smaller TTL for the end users. Thus, the dCDN
> supports a higher impact on requests, protecting the uCDN origin. For that,
> CachePOlicy permits to define modifications on the Cache-Control directives
> sent by the uCDN origin. Apart of that, the force property permits to
> mandate the dCDN to use those values only in the case the uCDN origin does
> not set the Cache Control directives. (as a default value)
>
> *draft v01*
>
> *draft v02*
>
> *Question*
>
> 2.2
>
> 2.3.2
>
> add cross reference for HeaderTransform
>
> Missing in v2. Set for v3
>
> 2.2
>
> 2.3.2
>
> MI.AllowCompress: Without this metadata today, a dCDN is free to choose to
> compress? t feels more natural to make the default true or change the
> metadata to DisallowCompress?  Otherwise, without an FCI advertisement of
> whether the dCDN supports the metadata, it's hard to know what its default
> behavior will be?
>
> Without it, there is no enforcement from the uCDN about dCDN behavior for
> compression. The purpouse of the functionality is to force compression in
> dCDN independently of how the uCDN content has been acquired. Agreed
> probably the name does not reflect precisely the functionality, and
> something like EdgeCompress or ForceCompress would be more suitable. In
> discussion in the SVA OCWG
>
> 2.3
>
> 2.1.1
>
> I'm curious about the use case.  The uCDN could just set the desired cache
> policy in the response, rather than setting the metadata.  Is the primary
> use case where the uCDN does not want to set the cache policy in each
> response and wants a default in the metadata?  Or is there something else?
> Is it to have a push interface (note: the triggers API provides a way to
> invalidate)?
>
> Cache Control directives condition how any cache system in the path
> between the uCDN origin and the user agent should behave. As the uCDN can
> only use one specific Cache-Control header, it has no flexibility to
> control the TTL of the objects in a dCDN cache. It would be the same for
> the dCDN cache and for an intermediate cache system.
>
> As the uCDN can have control over the objects the dCDN stores (as with the
> trigger interface mentioned) it can be of the uCDN interest to have a
> longer TTL for the dCDN Caches (so there is less traffic to the uCDN
> origins) but having a smaller TTL for the end users. Thus, the dCDN
> supports a higher impact on requests, protecting the uCDN origin. For that,
> CachePOlicy permits to define modifications on the Cache-Control directives
> sent by the uCDN origin. Apart of that, the force property permits to
> mandate the dCDN to use those values only in the case the uCDN origin does
> not set the Cache Control directives. (as a default value)
>
> *draft v01*
>
> *draft v02*
>
> *Question*
>
> 2.6
>
> 2.1.2
>
> "it may be desirable to cache error responses at the uCDN for a short
> period of time to prevent an overwhelmed origin service from being flooded
> with requests"?  Replace 's/uCDN/dCDN/' and 's/origin service/uCDN/' ?
>
> Could the uCDN specify the cache policies in the response?
>
> Removed that sentence.
>
> For the second questions: Same case as for MI.CachePolicy above. In fact,
> this could be considered a particular case of the MI.CachePolicy for
> errors. The uCDN can of course set the cache control directive for those
> errors. But it is typical the uCDN prefers to protect its origin server of
> a flood of requests when a non-desirable situation occur (an HTTP 500 error
> for example), but wanting the UA to try a faster revalidation. Other
> example, in the opposite way: A video fragment is not available yet in the
> uCDN Origin but published in a manifest (Live DASH). The UA requests a
> video fragment to the dCDN, and the dCDN requests it to the uCDN. When
> having an HTTP 404 error (because maybe the object is in the process of
> being available in the origin). If it sets a max-age of 10s in the
> response, the dCDN will not revalidate the object until 10 seconds has
> passed, so every UA trying to get the object will receive a 404 during 10
> seconds. But maybe the resource became available after just 1 second of the
> first request. The first UA that requested the fragment will wait 10s to
> get it again, but the rest of UA trying to access the same fragment will
> get it right away.
>
> 2.7
>
> 2.1.4
>
> Is the intent that this metadata would be pulled from the uCDN on every
> request and that the uCDN would made decisions based on the requestor:
> "CacheBypassPolicy only applies to the current request"?  Though not
> explicity prohibited by the MI, it goes a bit beyond the original intent of
> the metadata cacheability.
>
> Corrected the description. No relationship with the UA current request.
> This metadata applies after is received in a configuration, for all the
> requests that arrived since that moment that match the MI.ExpressionMatch
> and onwards. For the same resource requested, the dCDN can have a cached
> copy for those requests that don´t match the condition, while requesting a
> new copy for those that match.
>
> 2.8.1
>
> 2.3.4.1
>
> Combine the two Mandatory-to-Specify bullets?
>
> Corrected
>
> *draft v01*
>
> *draft v02*
>
> *Question*
>
> 2.9.1
>
> 2.5.2.1
>
> Do you envision a registry for the private features?
>
> By definition, the possible PrivateFeatures are implementation specific.
> As there could be a great variability on the possible properties we have
> not discussed the idea of having a registry. An uCDN configuring a
> HostMatch on multiple dCDNs should send a MI.PrivateFeatures metadata in
> the configuration only for those that support it, and the content
> particularized for each of those. As being a point to point configuration
> does not seem needed to have a registry.
>
> 2.12
>
> 2.5.3
>
> I would expect the type to come from the redirection modes registry (*https://www.iana.org/assignments/cdni-parameters/cdni-parameters.xhtml#capabilities-redirection-modes
> <https://www.iana.org/assignments/cdni-parameters/cdni-parameters.xhtml>*
> )?
>
> It is not exactly the same. FCI.RequestRouting and MI.RequestRouting are
> related to how the dCDN will make the Request Routing internally to direct
> the user to the suitable streamer. In the reference mentioned, the types
> HTTP-I or HTTP-R include the interative or recursive methods, while the
> internal request routing in a dCDN is independent of those techniques.
>
> The most typical use case is that a uCDN make a Traffic delegation using
> DNS-I or DNS-R, but wants to be sure that the dCDN is not going to do a
> internal HTTP redirection. Thus, sending MI.RequestRouting as “DNS” force
> the dCDN to use DNS RR internally and to avoid HTTP 302.
>
> 2.13
>
> 2.5.1
>
> I'm not clear what the two tiers are. In the case of a static ID, would
> the existing ccid metadata (*https://datatracker.ietf.org/doc/html/rfc8006#section-4.2.8
> <https://datatracker.ietf.org/doc/html/rfc8006>*) suffice?
>
> Description expanded to clarify that point. This extension permits to
> identify services AND properties in the service. So in the case of a static
> ID without any property identification, Grouping could be sufficient.
>
> *draft v01*
>
> *draft v02*
>
> *Question*
>
> 2.14.1
>
> 2.2.1.1
>
> For ease of understanding, should probably just duplicate the
> acquistion-auth, endpoints, and protocol properties
>
> Done
>
> 2.14.2
>
> 2.2.1.2
>
> - section 2.14.2: Is the intent to create a registry for load balancing
> algorithms?
>
> In discussion
>
> 2.16
>
> 2.3.3
>
> "vod" and "live" are fairly video specific; could this be more generically
> categorized?  is the intent to convey information about source acquisition
> (e.g., you may have to wait for live content to become available vs you may
> be able to prefetch vod), delivery pacing or rate limiting, both, neither,
> or other?
>
> The intention is related to the content delivery, not the content
> acquisition. In HTTP Adaptative Streaming protocols, the behaviour of the
> end users consumers (aka ‘players’) is quite different and it affects the
> content delivery resources depending on this type. While a live content is
> mainly RAM consuming, a VoD content is storage consuming. CDNs typically
> can apply different optimizations, including using different hardware
> elements depending on the type of the content. Thus, it is very important
> that in video streaming processes the dCDN knows that information in
> advance so it can apply those strategies, so the QoE will be superior.
>
>
>
> ------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is confidential and
> privileged information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni
>