Re: [httpstreaming] Current Status and Our Goal

[Qin Wu <[e-mail]>]

> 1) On the topic of this list/HTTP streaming, what do you think is the
> problem/problems/scenario we should be looking at?
> 

I do not feel I am in a position just yet to start making statements about what problems I think a HTTP streaming group (if formed) should look at, however one area that I think may be interesting to study and that I am not aware of other bodies looking at is "chunk hints".

A lot of streaming media today is delivered via CDNs that operate as more than just a dumb (inline) proxy cache.

HTTP naturally supports the insertion of caches transparently to the end points so one could argue that nothing more needs to be done for HTTP streaming than for regular HTTP.

As adaptive bit rate combined with HTTP delivery relies on throughput measurements to determine the appropriate bit rate to download for subsequent chunks, variation in latency (e.g. the difference between a request for a chunk being a cache hit Vs a cache miss) is likely to affect the throughput perceived by the client and therefore may cause bit rate switch on a cache miss that wouldn't have occurred had the request actually been a cache hit.

If there was some way to provide a "hint" to the server/cache as to which chunk the client is likely to request next then a CDN could elect to retrieve that chunk ahead of it actually being requested to keep the response latency (or some other factor) more consistent and avoid additional bit rate switches.

[Qin]: Good input, that's one issue we are addressing in the problem statement draft, i.e., Lacking Streaming Monitoring and Feedback Support. I think the chunk hint will be also very useful in case chunks loss or any exception as regarding to sever and network condition happens. Another advantage is with such chunk hints, we may not rely on manifest and playlist to fetch the chunks one by one. The problem is do we have approach to provide such hint to the server/cache?