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

From: Andrew Ryan <[email-masked]>
Date: Tue, 5 Apr 2022 08:56:42 -0400

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: "Chaudhari, Pankaj" <[email-masked]>
Date: Tue, 5 Apr 2022 14:54:48 +0000

+1 for adoption of this work.

- Pankaj

From: CDNi <[email-masked]> on behalf of ALFONSO SILONIZ SANDINO <[email-masked]>
Date: Thursday, March 24, 2022 at 1:42 AM
To: "[email-masked]" <[email-masked]>
Subject: [CDNi] Request for WG Adoption: CDNI Metadata Model Extensions

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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-goldstein-cdni-metadata-model-extensions%2F&data=04%7C01%7Cpc.chaudhari%40disneystreaming.com%7Cd3bb486249574853d32908da0d724675%7C65f03ca86d0a493e9e4ac85ac9526a03%7C0%7C0%7C637837081723867608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tFZhJVRWBuPPZ1LDJoyVeZij4kwOdbFNM%2FnQWKR98Uc%3D&reserved=0>

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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fcdni-parameters%2Fcdni-parameters.xhtml&data=04%7C01%7Cpc.chaudhari%40disneystreaming.com%7Cd3bb486249574853d32908da0d724675%7C65f03ca86d0a493e9e4ac85ac9526a03%7C0%7C0%7C637837081723867608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=cTS3vy%2B%2Bkn9wSbTkJ6qPZWGGvJVY9NK1e8w%2Bk7ZIrzM%3D&reserved=0>)?
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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8006&data=04%7C01%7Cpc.chaudhari%40disneystreaming.com%7Cd3bb486249574853d32908da0d724675%7C65f03ca86d0a493e9e4ac85ac9526a03%7C0%7C0%7C637837081723867608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=if3UnISnYnN%2F%2BgT1h8LE8mqvYGoEpnXBYiXed3RWQtg%3D&reserved=0>) 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