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

[Andrew Ryan <[e-mail]>]

I support the adoption of the daft

Andrew Ryan

On 3/24/2022 4:42 AM, ALFONSO SILONIZ SANDINO 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