Re: [httpstreaming] Current Status and Our Goal

Qin Wu <sunseawq@huawei.com> Thu, 14 October 2010 06:40 UTC

Return-Path: <sunseawq@huawei.com>
X-Original-To: httpstreaming@core3.amsl.com
Delivered-To: httpstreaming@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA1D3A6822 for <httpstreaming@core3.amsl.com>; Wed, 13 Oct 2010 23:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.973
X-Spam-Level:
X-Spam-Status: No, score=0.973 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh-+2708+FSX for <httpstreaming@core3.amsl.com>; Wed, 13 Oct 2010 23:40:33 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 16E593A6774 for <httpstreaming@ietf.org>; Wed, 13 Oct 2010 23:40:33 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA9002I5P9GUG@szxga03-in.huawei.com> for httpstreaming@ietf.org; Thu, 14 Oct 2010 14:41:40 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA900JVVP9GXZ@szxga03-in.huawei.com> for httpstreaming@ietf.org; Thu, 14 Oct 2010 14:41:40 +0800 (CST)
Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA900F50P9FM2@szxml06-in.huawei.com> for httpstreaming@ietf.org; Thu, 14 Oct 2010 14:41:40 +0800 (CST)
Date: Thu, 14 Oct 2010 14:41:39 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Mark Watson <watsonm@netflix.com>
Message-id: <03e201cb6b6a$db1ae770$30298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: multipart/alternative; boundary="Boundary_(ID_ExWOXQtFeP9X3i6XsmGg6w)"
X-Priority: 3
X-MSMail-priority: Normal
References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <4FFB3304-9F44-454D-9AF3-6194045F1030@netflix.com> <029d01cb693a$7f515f50$30298a0a@china.huawei.com> <9062141B-82B8-4FF0-98C2-EB803BCA3DD7@netflix.com>
Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org>
Subject: Re: [httpstreaming] Current Status and Our Goal
X-BeenThere: httpstreaming@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming>
List-Post: <mailto:httpstreaming@ietf.org>
List-Help: <mailto:httpstreaming-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2010 06:40:36 -0000

Hi,
  ----- Original Message ----- 
  From: Mark Watson 
  To: Qin Wu 
  Cc: Ali C. Begen (abegen) ; httpstreaming@ietf.org ; Colin Perkins 
  Sent: Tuesday, October 12, 2010 12:50 AM
  Subject: Re: [httpstreaming] Current Status and Our Goal


  Some comments online ...

  Sent from my iPhone

  On Oct 11, 2010, at 7:50 PM, "Qin Wu" <sunseawq@huawei.com> wrote:


    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: httpstreaming@ietf.org ; 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.Can you be more explicit about the problems that you see? I'm not sure where the 20s figure comes from. I do not see any problem in supporting startup times comparable to TV channel change with adaptive HTTP streaming.


  I am not saying there is no room for improvement in the various deployed systems, but I do not see major technical impediments to efficient delivery of high quality video using HTTP Streaming.

  [Qin]:Not only starup latency but also delay w.r.t. real time streaming. I think you negect it becos You didn't get into the discussion list. 

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.

  [MW] what do you mean by' http streaming server' ?

  [Qin]: With streaming capability and functionality to respond to HTTP connection.

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

  [MW] maybe we mean different things by 'available bandwidth'. Do you think it is a server scalability problem, or a network problem ?

  [Qin]: please read http://www.ietf.org/mail-archive/web/httpstreaming/current/msg00011.html

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

  [MW] Yes, but not a problem for the IETF, I think.

  [Qin]: I didn't get what you said. adaptive HTTP streaming algorithms is characterized as  client initiated pull model. We are discussing push model or how to use pull model with push model.We are talking about different model. There are plenty room for IETF to do for this.

   - 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.[MW] Again, the experience of millions of existing customers refutes what you claim. Why do you think it is necessarily so slow to issue a new HTTP request for a different part of the content?

  [Qin]: You didn't see the reaon behind this, becos the existing customers has no choice when they view live streaming, what they can get is close to live experience rather than real time user experience. Operatoer do nothing for their network to make http streaming more controllable and managable. Therefore more and more consumer tend to choose non-live content. that's why we see more and more non-live content consumers rather than live contents consumers. 


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: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Lars Eggert

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

          To: Colin Perkins

          Cc: httpstreaming@ietf.org

          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
        httpstreaming@ietf.org
        https://www.ietf.org/mailman/listinfo/httpstreaming






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


      _______________________________________________
      httpstreaming mailing list
      httpstreaming@ietf.org
      https://www.ietf.org/mailman/listinfo/httpstreaming