Re: bandwidth conservation use case, objection to use of Range for non-byte sections

On 9 March 2010 18:09, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> On Tue, Mar 9, 2010 at 7:51 PM, Conrad Parker <conrad@metadecks.org> wrote:
>> On 9 March 2010 17:37, Yves Lafon <ylafon@w3.org> wrote:
>>> On Tue, 9 Mar 2010, Conrad Parker wrote:
>>>
>>>> Hi,
>>>>
>>>> I would like to introduce a use cases that is not covered by the
>>>> existing specification: that a user agent may wish to retrieve a media
>>>> resource in chunks, so that the amount of content buffered ahead of
>>>> the user's current play position does not grow too large.
>>>>
>>>> In order to handle this use case, i propose to introduce a new HTTP
>>>> Request and Response header pair. Following the naming of yesterday's
>>>> F2F discussions, these could be Range-Equivalent and
>>>> Content-Range-Equivalent; they could similarly be part of whatever
>>>> Fragment and Content-Fragment are now being called. Let's call it Foo.
>>>> The syntax would be as has been suggested for non-byte dimensions of
>>>> Range/Content-Range.
>>>>
>>>> Then, a user agent wishing to retrieve the first 10kB of the resource
>>>> http://example.com/video.ogv#t=10,20 would translate this into:
>>>>
>>>> Range: bytes=0-10000
>>>> Foo: t:npt=10-20
>>>>
>>>> An origin server would respond with:
>>>>
>>>> Content-Range: bytes 0-10000/*
>>>> Content-Foo: t:npt 10-20/0-75
>>>> Vary: Content-Foo
>>>
>>> Does it mean that you are 100% sure that the time interval will match to the
>>> byte the byte interval?
>>
>> No, I don't expect that and it is not relevant.
>>
>>> Your use case is better addressed through heuristics and using only byte
>>> ranges. (with some part of decoding, you can infer the average amount of
>>> bytes for some amount of time).
>>
>> That would address a different concern. Here I'm simply talking about
>> transferring the data for 10-20s a few kB at a time.
>>
>> Conrad.
>>
>>>
>>>> The use of a header other than Range for non-byte sections has various
>>>> advantages:
>>>>
>>>> 1. As a consequence, an existing, HTTP/1.1 compliant intermediate
>>>> caching proxy would cache this response and could re-use it when
>>>> providing all or part of a subsequent request for
>>>> http://example.com/video.ogv#t=10,20. For example, the response
>>>> containing only the first 5kB of the resource would be:
>>>>
>>>> Content-Range: bytes 0-5000/*
>>>> Content-Foo: t:npt 10-20/0-75
>>>> Vary: Content-Foo
>>>>
>>>> Such a caching proxy would separately cache parts of the response
>>>> generated by the origin server for
>>>> http://example.com/video.ogv#t=30,40 as indicated by the Vary header.
>>>
>>>
>>>>
>>>> 2. This mechanism can be used in cases where the client specifies only
>>>> "Accept-Ranges: bytes" (ie. all current browsers and proxies)
>>>>
>>>> 3. Only the media-related URL translation parts of user agents and web
>>>> servers would require modification to support this mechanism; whereas
>>>> if a new Range dimension is introduced, the transport portions of web
>>>> servers, the caching portion of user agents, and the caching portion
>>>> (ie. all) of caching proxies and content distribution networks would
>>>> need to be re-implemented to allow such ranges to be cached.
>>>>
>>>> Semantically, I see the Foo header as describing a desired
>>>> representation (much like language handling), but Range has a
>>>> lower-level function related to transport and caching. I think it is
>>>> useful to allow both concerns to be handled by HTTP, which is
>>>> difficult if Range is overloaded.
>>>>
>>>> I think it is useful to agree on a specification that meets the aims
>>>> of this working group without requiring all WWW implementations to be
>>>> rewritten. Hence I object strongly to
>>>>
>>>> http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers
>>>> and instead suggest the use of this minor variation that does not
>>>> overload the existing Range/Content-Range transport mechanism.
>>>>
>>>> Concerning the process of resolutions: I was not present for that
>>>> resolution as it was after midnight here, and had already raised this
>>>> objection and suggestion during the teleconf prior to its discussion.
>>>>
>
>
> I think I am starting to understand: what if we want to do what all
> the browser vendors do: download a resource successively? But we only
> want to do it for a specific fragment?

Right, that's the general issue.

> I would think the byte ranges should actually be enough for that - the
> UA can administer what fragment it needs. No?

I think you are implying the case where a UA can seek on a single
media resource by byte ranges (by itself, without instructions from
the server). That is not the general case as it is media-type
specific, and in such a case we would not be using any form of time
range request headers so that case is moot.

I'm suggesting that in the case where a UA wants to use HTTP headers
to request a temporal or spatial representation, an HTTP request
header other than Range is used to specify that, in order that Range
can be used for partial retrieval.

Conrad.

Received on Tuesday, 9 March 2010 09:18:19 UTC