[whatwg] Limiting the amount of downloaded but not watched video

[Glenn Maynard]

On Wed, Jan 19, 2011 at 8:22 AM, Philip Jägenstedt <philipj at opera.com>wrote:

> If the available bandwidth exceeds the bandwidth of the resource, some kind
> of throttling must eventually be used. There are mainly 2 options for doing
> this:
>

> 1. Throttle at the TCP level by not reading data from the socket (not at
> all to suspend, or at a controlled rate to buffer ahead)
> 2. Use HTTP byte ranges, making many smaller requests with any kind of
> throttling at the TCP level
>

You're talking about Opera's implementation and not in spec, right?  This is
something UA's should have a lot of freedom with, and I assume this
low-level detail about how to use HTTP is out of scope for the HTML spec.


> (Since there is some overhead with each HTTP request, one must make sure
> that they are not unreasonably small.)
>
> When HTTP byte ranges are used to achieve bandwidth management, it's hard
> to talk about a single downloadBufferTarget that is the number of seconds
> buffered ahead. Rather, there might be an upper and lower limit within which
> the browser tries to stay, so that each request can be of a reasonable size.
> Neither an author-provided minumum or maximum value can be followed
> particularly closely, but could possibly be taken as a hint of some sort.
>

Does it actually make sense to specify the read-ahead size, or should it
simply be a flag (eg. "unlimited", "small buffer" and "don't care")?  Is
there really a case for setting the actual read-ahead value directly?  In a
sense, that seems akin to allowing web pages to control the TCP buffer sizes
used by the client's browser--it's lower level than people usually care
about.

In particular, I'm thinking that most of the time all people care about is
"read ahead a little" vs. "read ahead a lot", and publishers shouldn't need
to figure out the right buffer size to use for the former (and very likely
getting it wrong).

-- 
Glenn Maynard