Re: [httpstreaming] Charter Skeleton draft- Your thoughts are requested

[Ben Niven-Jenkins <[e-mail]>]

Qin, Colleagues,

Reading the draft charter below and draft-wu-http-streaming-optimization-ps-02 it is not clear to me what the intended purpose of a httpstreaming working group would be, in other words what specific problems (or problem areas) would an httpstreaming group address?

Both the wu-http-streaming draft and the draft charter put forward a number of perceived problems with 'HTTP Streaming' in general but it is not clear which of them, if any, it is intended that a httpstreaming group work on.

For example, from the draft/charter I could take away the impression that the intent is to:
- Identify shortcoming in the HTTP protocol itself and improvements to HTTP that could make HTTP based streaming "better" (for some definition of "better")
- Specify a different protocol to HTTP for streaming data
- Specify a different transport layer for HTTP to avoid the problems raised in wu-http-streaming caused by TCP
- Specify how an application running over HTTP should operate in order to be able to implement  HTTP streaming and avoid certain challenges/issues etc
- all the above
- something entirely different.

I think the charter needs to be much more tightly focussed on what areas will/will not be in scope. This should make it much easier to assess whether the proposed work is something that is complementary to or competing with other efforts in other bodies and where any commonalities/synergies exist.

Some specific comments of the draft charter text in-line

On 25 Sep 2010, at 05:05, Qin Wu wrote:
> --------
> Goal:
> Focus on work which will address relevant issues facing the network operator community today.
> In particular an effort will be made to address gaps and issues in currently understood best practices for
> forwarding, control plane, and management plane and seek network capability to control and manage HTTP Streaming.

This is very vague. "forwarding, control plane, and management plane" at which 'layer'? Is this talking about improving the actual network routers/switches, interaction with application (e.g. HTTP) proxy caches, how to provision & manage an actual Streaming service, etc.
 
> Background:
> Streaming service is described as transmission of data over network as a steady continuous stream, allowing playback
> to proceed while subsequent data is being received, which may utilize multiple transport protocols for data delivery.
> HTTP streaming refers to the streaming service wherein the HTTP protocol is used for basic transport of media data.
> One example of HTTP streaming is progressive download streaming which allows the user to access content using
> existing infrastructure before the data transfer is complete.
>  
> Since HTTP streaming takes Existing HTTP as data transport (i.e., HTTP 1.1) and HTTP is operated over TCP, it is
>  much more likely to cause major packet drop-outs and greater delay due to TCP with the characteristic which keeps
> TCP trying to resend the lost packet before sending anything further.

"it is much more likely to cause major packet drop-outs and greater delay" compared to what?

Any problem here would appear not to lie with HTTP itself (except that it has chosen TCP as its transport protocol), many other streaming protocols such as RTMP, RTSP, MMS etc. support TCP based transport, do these suffer from the same issues? If not what is special about the HTTP case?

> One way to reduce major packet drop-outs is to
> introduce media segmentation capability in the network behind media encoder, i.e., using segmenter to split the input
> streaming media into a serial of small chunks and meanwhile creating manifest file containing reference to each chunks.

I don;t see how media segmentation reduces packet drops. I can see that it may allow you to reduce the impact if you have multiple connections in parallel as a packet drop would only block one of the open sockets and the others could continue to receive data.

> Allowing such streaming media segmentation can mitigate great delays and breakups during streaming playout.

Is it actually the media segmentation that mitigate the delays & breakups or the fact it is being combined with adaptive bit rate delivery?

>  
> Why HTTP Streaming:
> As the HTTP protocol is widely used on the Internet as data transport, it has since been employed extensively for the delivery of multimedia content. A significant part of the
>  Internet traffic today formly generated by P2P application has been eclipsed by streaming, CDN and direct download.
> Another trend is the growing popularity of connected devices like Smartphones, TVs, PCs and tablets is raising interest
> in multi-screen services that enable consumers to access the same media content and quality of experience (QoE) on any
> device, anytime and anywhere. Since almost all the connected devices have browser support, but not all of them can
> afford high CPU load and batteries draining as TVs or PCs, it is obviously a best choice to use HTTP streaming to
> support multi-screen video delivery.
>  
> Problems: (The challenging of the existing work on HTTP streaming)
> With media segmentation support, existing streaming technology (e.g., progressive download streaming)
> is characterized as client based pull schemes and more relies on client to handle buffer and playback during
> download. However streaming long duration and high quality media over the internet has several unique Challenges:
> –    Client polling for each new data in chunks using HTTP requests is not efficient to deliver high-quality video content across the Internet

I think it may be worthwhile to separate "efficient" from "good enough". Polling may not be efficient in terms of the number of requests/responses during playout but is it so inefficient that it actually affects the performance of a client or the scale of a server (e.g. because requests may become synchronised) performing HTTP streaming?

> –    Segmentation capability requires over-utilizing CPU and bandwidth resources, which may not be a desirable and effective way to improve the quality of streaming media delivery

I don't really understand why segmentation itself would lead to over-utilized CPU or bandwidth resources.

> –    Lack of QoS guarantee on the packet switching based Internet , the quality of Internet media streaming may significant degrade due to rising usage

This may be true but is the intent for an httpstreaming group to do something about it?

> –    Experience burstiness or other dynamics changes due to bandwidth fluctuations and heterogeneous handover.

Is this not a generic issue not specific to HTTP streaming?

> –    Impossible to fast-forward through any part of a streaming contents until it is stored on the user's device

Is this really a problem with HTTP streaming or more with the currently defined manifest & media file formats not supporting an equivalent of a trick play file?

> Given these challenges, the typical user experience can be limited by delayed startups, poor quality, buffering delays, and inadequate playback control.

How much of these are down to HTTP specifically versus those shared by most/all other streaming protocols? Does HTTP perform significantly worse than other streaming protocols in these areas?

>  
> Scope:
> a. Exploration of problem inherent in HTTP streaming.
>  
> b.Proposals for new approaches to operational challenges metioned above.
> In order to address those above challenges effectively , the group may consider to design and specify  
> network based HTTP Streaming schemes/protocol that will offer efficient and network-friendly transport
> with QoS/QoE guaranteed and the feedback on quality of data delivery.

This may be somewhat premature until it is clearer where the real issues with HTTP Streaming lie - i.e. do they require a new application specification, a tweak to an existing application specification or are they solvable in other ways - e.g. choice of a different transport protocol.

>  HTTP Streaming applications can rely
>  on the server side to detect the user's connection speed and select the streaming contents with the appropriate
>  encoding rate for smooth, uninterrupted playback. Also it can choose to switch between push or pull using the
> better transport.

I am not sure why the server side should detect the user's connection.

> As a simple example, the server keeps on pushing data chunks to the client and the client communicates
> with the server over a full-duplex TCP connection to convey feedback on quality of data delivery. And then the server
> tunes the parameters such as buffer size and bandwidth according to QoS feedback and network load. In case of streaming
> changes or failover, the server may send notification event to the client. Though there are existing server push schemes
> (e.g., Server Sent Event, XMLHttpRequest, iFrame,WebSocket), however they might be lack capability for
> providing feedback on quality of data delivery.

I would not include an example solution in the charter - if definition of a new application/protocol is in scope then state that, but giving example solutions tends to confuse & distract during discussions/BoFs more than it helps IME.

> 
> Non-Goal:
> Playlist format and Streaming file format should be beyond scope of this charter.

It's not clear to me how this marries with Scope (b) that implies a new HTTP streaming application may be specified by the group, but that the companion manifest & media file formats won't be specified. Maybe this split will become clearer as the other items I raise are addressed.

Regards
Ben