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
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Wenbo Zhu
- Re: [httpstreaming] Current Status and Our Goal David A. Bryan
- Re: [httpstreaming] Current Status and Our Goal Ben Niven-Jenkins
- Re: [httpstreaming] Current Status and Our Goal Luby, Michael
- Re: [httpstreaming] Current Status and Our Goal Daniel Park
- Re: [httpstreaming] Current Status and Our Goal Roni Even
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Roni Even
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Kathy McEwen
- Re: [httpstreaming] Current Status and Our Goal Marshall Eubanks
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Kathy McEwen
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Kathy McEwen
- Re: [httpstreaming] Current Status and Our Goal Colin Perkins
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Lars Eggert
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Mark Watson
- Re: [httpstreaming] Current Status and Our Goal Ye-Kui Wang
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Wenbo Zhu
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Wenbo Zhu
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Wenbo Zhu
- Re: [httpstreaming] Current Status and Our Goal Mark Watson
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Wenbo Zhu
- Re: [httpstreaming] Current Status and Our Goal Lars Eggert
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Mark Watson
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Ning Zong
- Re: [httpstreaming] Current Status and Our Goal Mark Watson
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Ning Zong
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Wenbo Zhu
- Re: [httpstreaming] Current Status and Our Goal Ye-Kui Wang
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- Re: [httpstreaming] Current Status and Our Goal Qin Wu
- [httpstreaming] Push Vs Pull (was Re: Current Sta… Ben Niven-Jenkins
- Re: [httpstreaming] Push Vs Pull (was Re: Current… Qin Wu
- Re: [httpstreaming] Push Vs Pull (was Re: Current… Mark Watson
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)
- Re: [httpstreaming] Push Vs Pull (was Re: Current… Ning Zong
- [httpstreaming] Push Vs Pull Re: Current Status a… Qin Wu
- Re: [httpstreaming] Push Vs Pull Re: Current Stat… Qin Wu
- Re: [httpstreaming] Push Vs Pull Re: Current Stat… Thomas Stockhammer
- Re: [httpstreaming] Push Vs Pull Re: Current Stat… Qin Wu
- Re: [httpstreaming] Push Vs Pull Re: Current Stat… Thomas Stockhammer
- Re: [httpstreaming] Push Vs Pull Re: Current Stat… Qin Wu
- Re: [httpstreaming] Push Vs Pull Re: Current Stat… Thomas Stockhammer
- Re: [httpstreaming] Push Vs Pull Re: Current Stat… Wenbo Zhu
- Re: [httpstreaming] Current Status and Our Goal Colin Perkins
- Re: [httpstreaming] Current Status and Our Goal David R Oran
- Re: [httpstreaming] Current Status and Our Goal Benjamin Niven-Jenkins
- Re: [httpstreaming] Current Status and Our Goal Thomas Stockhammer
- Re: [httpstreaming] Current Status and Our Goal Colin Perkins
- Re: [httpstreaming] Current Status and Our Goal Spencer Dawkins
- Re: [httpstreaming] Current Status and Our Goal Wenbo Zhu
- Re: [httpstreaming] Current Status and Our Goal Ning Zong
- Re: [httpstreaming] Current Status and Our Goal Ning Zong
- Re: [httpstreaming] Current Status and Our Goal Ali C. Begen (abegen)