Re: [httpstreaming] Current Status and Our Goal

[Qin Wu <[e-mail]>]

Hi,
This is what we had discussed  in the DISPATCH mailing list before we move to this discuss list.
If you look at the description of discuss list, "
offers more efficient transport 
and better network capability for real time streaming media
and allows interoperability with other streaming techniques and existing Progressive dowloaded based
HTTP streaming implementation.
"
you will see we are on the same page.
Therefore one important goal discussed in the draft aims at developing interoperable solution to 
provide better transport to satisfy the real time streaming QOE requirement. Especially serveral
chanllenges/problems we explored in the draft listed below.

Regards!
-Qin
  ----- Original Message ----- 
  From: Mark Watson 
  To: Ali C. Begen (abegen) 
  Cc: [e-mail] ; Colin Perkins 
  Sent: Sunday, October 10, 2010 7:13 AM
  Subject: Re: [httpstreaming] Current Status and Our Goal


  All,


  I would like to add my support to the comments below. Specifically, I think if the IETF considers work in this area it should focus on the HTTP and TCP protocols. Any such work may not be specific to HTTP-streaming (i.e. enhancements that are at first motivated by HTTP Streaming may have broader applicability, and this should be carefully considered).


  In the draft I do not see a clear or correct identification of the problems. For example in the introduction the following are stated as issues:
   - Client polling for each new data in chunks using HTTP requests is
   not efficient to deliver high-quality video content across the
   InternetMW: Several companies, including my employer, are successfully operating large scale HTTP streaming systems that do efficiently deliver high-quality video content across the Internet, so reality seems to refute this statement.[Qin]: Not sure they can provide the TV experience for all the connected devices like smartphones, PCs and tablets. Also not sure they can provide the same quality of experence for all the all the connected devices. As we discussed in this thread, a minimum of 20 seconds to start your video often frustrated users to keep on watching and provide very limited user experience.On the other hand, I think we should bear in mind HTTP is formerly designed for browsing webpage, transport static contents like HTML page, plugin, picture, when we are going to use HTTP to deliver real time streaming contents, we can not expect to get higher user experience. Therefore the current streaming schemes can only offer a better experience over slower connections.   - 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 deliveryMW: It is not clear that segmentation per se is CPU-intensive or has any non-negligable effect on bandwidth usage.[Qin]: Since HTTP streaming server is the combination of streaming server and regular web server, I think the answer is both.   - Lack of QoS guarantee on the packet switching based Internet , the
   quality of Internet media streaming may significant degrade due to
   rising usageMW: An alternative view is that where quality is degraded due to congestion this is due to lack of bandwidth, rather than a lack of QoS guarantees. Adaptive HTTP streaming systems adjust the video quality to the available bandwidth in order to avoid rebuffering events. It is the available bandwidth that needs to be improved to improve quality.[Qin]: What I emphasize here is with growing popularity of HTTP streaming traffic, when thousands or millions of people are accessing the same media contents, the big problem we are facing is serious high concurrence access issue. The user experience will be greatly affected even you have enough available bandwidth. So this is not pure bandwidth issue.   - Experience burstiness or other dynamics changes due to bandwidth
   fluctuations and heterogeneous handover.MW: We have found that adaptive HTTP streaming algorithms are well able to cope with bandwidth fluctuations. [Qin]: I don't doubt that adaptive HTTP streaming algorithms can cope with bandwidth fluctation. But I hope we can do better.e.g., adaptive HTTP streaming algorithms only support delivery of multiple streams of the same content with varying quality levels for different bandwidth or devices. Howeve how the server in push model or client in pull model can quick response to the bitrate changes is a problem we may look at,especially when switching beween streams occurs very frequently.   - Impossible to fast-forward through any part of a streaming
   contents until it is stored on the user's deviceMW: This is simply not correct, since there are hundreds of examples of devices which support trick-play using HTTP streaming techniques without storing the whole content on the users device.[Qin]: Fast forward capabilty is not the most important feature we are looking for. However I am hard to believe existing HTTP streaming techniques can provide the same degree of playbackcontrol that DVD player can provides or RTSP protocol provides. E.g., In the adaptive HTTP streaming algorithms, the trick play is limited to pause/resume/stop by driving the HTTP request. If the contents hasn't been dowloaded  and the consume want fast forward, the HTTP client needs to issue another new HTTP request to fetch the contents which willcause unacceptable latency to the consumer.A first step in considering what, if any, work should be done here might be to contact those organizations which are standardizing the higher layers of HTTP streaming systems (e.g. manifest and file formats) and ask whether there are deficiencies they see in IETF protocols that could be usefully addressed by the IETF. What I think we should avoid in the IETF is duplicating the work of these other bodies.Best,Mark WatsonNetflix Inc.





  On Oct 10, 2010, at 12:43 AM, Ali C. Begen (abegen) wrote:





      -----Original Message-----

      From: [e-mail] [mailto:[e-mail]] On Behalf Of Lars Eggert

      Sent: Friday, October 08, 2010 4:17 PM

      To: Colin Perkins

      Cc: [e-mail]

      Subject: Re: [httpstreaming] Current Status and Our Goal



      On 2010-10-7, at 14:16, Colin Perkins wrote:

        There are clearly some issues to consider here. What seems to be

        missing from the discussion to me though, is some identification of

        the concrete problems. What protocol pieces do we need, but not have?

        What protocols are problematic, and need enhancement? Is there

        protocol work to do in IETF, or should we be documenting best current

        practices for using the existing protocols and/or relying on other

        bodies to fill the gaps?



        The draft-wu-http-streaming-optimization-ps is a good start at such an

        analysis, but doesn't go deep enough to let us decide what work IETF

        should do.



      +1



      The key question really is "what do you think the IETF needs to do?"


    I imagine the only work the IETF should do (if we decide to) is the transport and HTTP-layer optimization for better streaming performance.

    -acbegen


      Lars

    _______________________________________________
    httpstreaming mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/httpstreaming






------------------------------------------------------------------------------


  _______________________________________________
  httpstreaming mailing list
  [e-mail]
  https://www.ietf.org/mailman/listinfo/httpstreaming