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

[Qin Wu <[e-mail]>]

Hi, Ben:
Thank for your valuable input and comments. In my personal opinion, our goal is to talk about how to enrich network capability
to well control and manage HTTP streaming and how to utilize HTTP streaming to support multiple screen service. The QoS/QoE requirement
is a big challenge to HTTP streaming. We have identified lots of interesting issues in the DISPATCH discussion. Also I raise lots of serious issues
in draft-wu-http-streaming-optimization-ps-02. 

So the main purpose of this discussion list to get people agreed what problem we need to solve and 
gain an understanding of the directions forward.

The draft charter and draft-wu-http-streaming-optimization-ps-02 are primarily used to form our discussion basis and throw out a minnow to catch a whale.
But you are right, we are at the cross road when seeking concrete protocol mechanism for the problems we identified.:-)

As for your detailed comments, please see my reply belows.

Regards!
-Qin
----- Original Message ----- 
From: "Ben Niven-Jenkins" <[e-mail]>
To: "Qin Wu" <[e-mail]>om>; <[e-mail]>
Sent: Wednesday, September 29, 2010 1:25 AM
Subject: Re: [httpstreaming] Charter Skeleton draft- Your thoughts are requested


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.

[Qin]: Thank for pointing out this.
I think the network capability should be bulit over network layer and sit between transport layer and application layer. The network we are talking about is CDN network, the actuall network components we are talking about include
HTTP streaming server, HTTP Streaming Proxy, HTTP streaming Client rather than regular network routers/switches. These components are combination of regular web server/proxy/browser and streaming functionality.
Hope this clarifies.
 
> 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?

[Qin]: Compared to taking UDP as transport.

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?

[Qin]: Good question. I think they may suffer the same issue when they take TCP as Transport. What is special about the HTTP case is unlike RTSP new extension, HTTP case does not have quality parameter at the HTTP layer which disallow mapping between quality parameter at the HTTP layer and rate parameter at the TCP layer. In other words, cross layer interaction between HTTP layer and TCP layer  is not allowed which may cause slow response of TCP when bandwidth fluctation or handover occurs.
But this may get too far away from what we focus. Transport area experts may be more intererested in such issue.

> 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.

[Qin]: Yes, media segementation can not root out large packet dropping. But it can in some degree mitigate packet drop and latency comparing with no segmentation.
If we want to eradicate ultimately large packet dropping due to TCP, we may need to relax TCP retransmission mechanism at the TCP layer. Does IETF transport area allow us to do this?

Another desirable way is to provide QoS/QoE guanranteed mechanism for HTTP Streaming which is used to satisfy real time streaming requirements.

> 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?

[Qin]:That's what I said above. We are on the same page now.:-)

>  
> 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?

[Qin]: Good point.

> –    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.

[Qin]: Segemation capability should be part of the server. The server can be split into web server and streaming server. The bottleneck of web server is bandwidth or network connections, the bottleneck of streaming server is CPU.
When the pre-recorded streaming content feeds the streaming server , it is not big deal for streaming server for break them into a serial chunks or clips or the pre-recorded contents has already been split into small chunks.
But  when the live streaming content feeds the streaming server, the streaming server demands extensive CPU power. This can be very expensive in terms of equipment, 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?

[Qin]: In my personal opinion, I think this part is worth being dug into.

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

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

[Qin]: This issue will be more serious for 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?

[Qin]: In my understanding, currently defined manifest& media file formats only can handle the dowloaded or stored static contents.they will fall short when they handle live contents and most of this live contents
hasn't  been dowloaded, that can not provide the same degree user experience as DVD viewing. 
You may argue that the manifest can be updated frequently when offer live content to the client, but when and how frequent the client fetch such updated manifest is one issue which may cause unacceptable user 
experience.

> 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?

[Qin]: The key difference between HTTP streaming and other streaming protocol is streaming content is delivered over Internet which can only provide better effort QoS guaranteed.
Therefore some people said if you look for amateur solution, please choose HTTP streaming, if you look for professonal solution, please choose other streaming technology like RTSP/RTP.
But now we are facing different situation, With growing populariy of multiple screen service, how to allow differnt type of client using browser  to access the same streaming media with the same Quality of Experience is a big
opportunity and great challenge.

>  
> 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.

[Qin]: Good point.

>  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.

[Qin]: Since we want to break client polling to provide more efficient delivery for real time streaming contents, the desirable way is to use server push like mechanism.
Since the server control and manage HTTP streaming, it is more efficient to let the server side to detect user connection and tune the frequecy of sending media segements.

> 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.

[Qin]: Okay.

> 
> 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.

[Qin]: I think it is better for us to say we will resue manifest & media file formats as one existing component. We are not intending to build any new component like manifest & media file formats.

Regards
Ben