Re: Issue with "bytes" Range Unit and live streaming

["Roy T. Fielding" <[e-mail]>]

> On Apr 20, 2016, at 2:08 PM, Craig Pratt <[e-mail]> wrote:
> 
> Reply in-line.
> 
> cp
> 
> On 4/20/16 1:14 PM, Matthew Kerwin wrote:
>> 
>> 
>> On 21/04/2016 5:37 AM, "Thorsten Lohmar" <[e-mail] <mailto:[e-mail]>> wrote:
>> >
>> > Hi Craig,
>> >
>> > > What *is* missing is the ability to get a continuous byte range on live content
>> > > that starts at an arbitrary offset and the ability to directly jump to the live
>> > > point.
>> >
>> > Yes, and there are two solutions to the issue:
>> > A. Enable it on HTTP Layer through the definition of a new range request method
>> > B. Enable working with existing HTTP procedures, i.e. client can workout the precise byte offsets.
>> 
>> C. Use a different URL (e.g. a ?start= query parameter). It's less optimal for caching, but it works today without any new specs.
>> 
> [cp] We can't use a different URI in our application (the UPnP CDS and DLNA RUIH guidelines only one URI per resource).
> 
> [cp] We can define a custom header. But (a) it appears that the feature we're describing has been requested many times over, (b) at least having an RFC enables caches to be implemented. Using a custom header or URI will require caching to be disabled by the origin server.
> 
> [cp] One point I haven't mentioned about caching with bytes-live: Since the bytes-live Range Unit is designed to work in concert with the bytes Range Unit (not superceded it), caching can still be performed by proxies that don't understand bytes-live. The read-through and hit ratio will be reduced. But there's still opportunities to cache.

This doesn't make any sense.  The live stream URI (whatever it is) always identifies
the current live stream head.  An HTTP cache cannot save that because each new request
expects the latest live stream.  What it can do is parallel cache the live stream's
representation under a different "past stream" URI (or an array of such) and include
instructions on how to use that within the live stream metadata.  Regardless, the live
stream HTTP response must be marked as non-cacheable to avoid filling up normal caches.

On balance, I think this is a poor use of HTTP.  The Apple live streaming protocol,
which is just a dynamically updated representation of a queue by reference, is
able to perform the same task without twisting backwards.  By indirectly referencing
the data streams, the primary queue can remain non-cacheable (until the stream dies
and is archived) without impacting (partial) requests on the referenced data streams.

....Roy