Re: [Hls-interest] LL-HLS Amendment Proposal: Optional part response headers for CDN efficiency.

> On Feb 9, 2021, at 7:54 AM, Andrew Crowe <acrowe=40llnw.com@dmarc.ietf.org> wrote:
> 
> Hello,
> 
> CMAF content packaged and delivered using LL-DASH and range-based LL-HLS are easily managed as duplicate content by CDNs as they specify only segment files. In fact, once the segment is complete, it can then be served out of CDN cache for players that are not Low Latency capable - effectively reducing latency for them as well. Part-based LL-HLS introduces individually named part files that then collapse to the separately named segment file upon final part completion. This then means that on first request for the whole collapsed segment file the CDN will have to go back to origin to request bytes that it likely already has in the individually named part files. CDNs can improve cache efficiency, origin hit rate, and whole segment delivery times with a little bit of additional information from origin.
> 
> 
> On request for a named part file an origin may provide a set of response headers:
> 
> *X-HLS-Part-Sequence*
> A multi value header that represents the current part sequence (index=1) and the total number of parts for the segment. The values will be separated by a forward slash ("/"). For example a 2 second segment with 8 parts per segment will respond to the 2nd part request (vid720_segment_1521.part2.m4v) like
> X-HLS-Part-Sequence: 2/8
> 
> 
> *X-HLS-Part-Offset*
> A single value header that represents the byte offset of the part in the segment. The first part of a segment will always be 0 while, for example the second .25s part of a 2mpbs stream (vid720_segment_1521.part2.m4v) may have a value like 623751
> 
> 
> *X-HLS-Part-Root-Segment*
> A single value header that provides the name of the root segment of the current part. This lets the CDN/proxy know which root file to concatenate the parts into. vid720_segment_1521.part2.m4v would have a value of vid720_segment_1521.m4v
> 
> 
> With the information from these three headers the CDN can recognize the individually named part files as ranges of a larger file, store them effectively and deliver a better experience to viewers across all formats. 

Hello Andrew. I’m interested in this proposal, but I’d also like to hear some feedback from others in the CDN and packager spaces. Specifically, I’d like to know if other folks:

- Agree that it’s a good way to solve the problem

- Can spot any problems or limitations in this proposal that might make it difficult to produce (or consume) these headers

- Can see themselves implementing it

thanks,

Roger Pantos
Apple Inc.

> 
> Regards,
> -Andrew
> -- 
>  <https://www.limelight.com/>
> Andrew Crowe Architect
> EXPERIENCE FIRST.
>  <>+1 859 583 3301 <tel:+1+859+583+3301>
> www.limelight.com <https://www.limelight.com/>
>  <https://www.facebook.com/LimelightNetworks> <https://www.linkedin.com/company/limelight-networks> <https://twitter.com/llnw>
> -- 
> Hls-interest mailing list
> Hls-interest@ietf.org
> https://www.ietf.org/mailman/listinfo/hls-interest