Re: [httpstreaming] Agenda and Slides

Xiangsong Cui <Xiangsong.Cui@huawei.com> Fri, 12 November 2010 02:19 UTC

Return-Path: <Xiangsong.Cui@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 709F33A6A9F for <httpstreaming@core3.amsl.com>; Thu, 11 Nov 2010 18:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.873
X-Spam-Level: *
X-Spam-Status: No, score=1.873 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1]
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 9McxZJkMXj0I for <httpstreaming@core3.amsl.com>; Thu, 11 Nov 2010 18:19:04 -0800 (PST)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 62C033A6AA6 for <httpstreaming@ietf.org>; Thu, 11 Nov 2010 18:19:04 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBR00J3R2GD8Y@szxga04-in.huawei.com> for httpstreaming@ietf.org; Fri, 12 Nov 2010 10:19:25 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBR00FM32GCEU@szxga04-in.huawei.com> for httpstreaming@ietf.org; Fri, 12 Nov 2010 10:19:24 +0800 (CST)
Received: from [172.24.1.3] (Forwarded-For: [130.129.116.45]) by szxmc03-in.huawei.com (mshttpd); Fri, 12 Nov 2010 10:19:24 +0800
Date: Fri, 12 Nov 2010 10:19:24 +0800
From: Xiangsong Cui <Xiangsong.Cui@huawei.com>
In-reply-to: <204E7666-5455-4F51-A865-9043BE3EE84B@cisco.com>
To: David R Oran <oran@cisco.com>
Message-id: <faeffe381fdd5.1fdd5faeffe38@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006)
Content-type: multipart/mixed; boundary="Boundary_(ID_BpLMJ+Hk40Yve0OhMNr3pQ)"
Content-language: zh-CN
X-Accept-Language: zh-CN
Priority: normal
References: <AANLkTimsEDGkDVjTj0uVg7g4h+L8JtmM7FJMRM4TvWtv@mail.gmail.com> <01df01cb8089$568d0b30$03a72190$@iridescentnetworks.com> <CEA40436-871D-4748-80F0-1D515E7ED054@netflix.com> <fba7d8a4195b6.195b6fba7d8a4@huawei.com> <20D6E2C9-8E84-42E8-8145-0AF0FE575AFE@cisco.com> <fba2dcf3187a6.187a6fba2dcf3@huawei.com> <204E7666-5455-4F51-A865-9043BE3EE84B@cisco.com>
Cc: httpstreaming <httpstreaming@ietf.org>
Subject: Re: [httpstreaming] Agenda and Slides
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: Fri, 12 Nov 2010 02:19:06 -0000

Hi David,

Again, I'm not telling any solid use case, just my some thoughts, or questions, for open discussion.
Please see my comments inline.



----- 原邮件 -----
发件人: David R Oran <oran@cisco.com>
日期: 星期四, 十一月 11日, 2010 下午11:44
主题: Re: [httpstreaming] Agenda and Slides
收件人: Xiangsong Cui <Xiangsong.Cui@huawei.com>
抄送: Mark Watson <watsonm@netflix.com>om>, httpstreaming <httpstreaming@ietf.org>

> 
> On Nov 11, 2010, at 4:10 AM, Xiangsong Cui wrote:
> 
> > Hi David,
> > 
> > In fact I have no clear picture in my mind, I am thinking,
> > 
> > #1, It seems the current adaptive HTTP streaming is based on 
> endpoint (client or server), is it possible or useful that the 
> middle-box trigers stream rate adjustment? 
> I sure hope not, unless by "middlebox" you mean a real HTTP server 
> at the edge of the CDN. Otherwise you get no sympathy from me as I 
> am on record as finding middleboxes a pretty universally bad 
> thing. If you mean special machinery in the edge HTTP server 
> looking into the access network (e.g. mobile, DSL, etc.) then I 
> think there *might* be something (as I said, I'm open minded), but 
> it's up to the proponents of doing stuff on the HTTP servers to 
> make the case that it provides more than a small measurable 
> benefit and doesn't break anything.

In my mind, that is not a HTTP server, but it will do some measurement on the HTTP traffic flow.
The baseline here is, it should not break anything in the HTTP transaction.

> 
> >    In my mind, a similar case is ECN mechanism, router forwards 
> IP packets between TCP endpoints. The router doesn't support TCP 
> protocol, but the router can be involved in TCP flow control (or 
> TCP rate adjustment) by some IP header indication.
> ECN does not involve the router in a TCP flow. What makes you 
> think it does? It's a pure L3 mechanism with no examination of TCP 
> headers nor tracking of TCP state.

I didn't say router is involved in TCP flow, My point here is, the router can influence TCP endpoint (rate control aspect) by some operation except dropping.
Router may drop packet, the TCP endpoint will also detect that, and the endpoint will give some reaction. This of course works well, but it is also may be improved, right?

> 
> > Can the middlebox also influence HTTP streaming by some 
> mechanism more effectively? I think network-based or network-
> involved HTTP streaming mechanism may be a supplement to client-
> based mechanism. 
> Well, the potential design space is gigantic. Most of it is 
> complicated and has lots of tradeoffs. Imagining that you might do 
> something better is not sufficient. You have to:
> a) propose something
> b) analyze it
> c) simulate it under a wide range of conditions
> d) implement it
> e) measure it on the real internet (or an overlay like Planetlab).

Yes, you are right, there are lots jobs, but I'm just wondering, is it possible?
Or maybe can tell me, why is it not possible? why is it not worthy of any consideration?

> 
> Get there and them maybe the IETF should have another BoF to look 
> at the problem.

If this is out of scope of httpatreaming list, we may discuss this somewhere others.

> 
> > RED is OK, but whether it is better that rate adjustment happens 
> earlier than packet drop? Some resource in the foregoing path is 
> wasted by dropped packets ...
> > 
> That's not what RED is about. It's about breaking up the well-
> known synchronization behavior of tail-drop on TCP, which leads to 
> oscillations and significant underutilization of bottleneck link 
> bandwidth. It isn't about improving the performance for any one 
> connection. RED is basic hygiene, not an optimization. My point 
> was that designing complicated TCP or HTTP level mechanisms to try 
> to get around tail-drop router induced performance problems is a 
> waste of effort when you can just torn on RED. What data do you 
> have that the performance anomalies you're trying to eliminate are 
> NOT due to tail drop?
> 
> > #2, In mobile envirment, network has a more clear map (channel, 
> bandwidth, etc.) than the client, if the network can trace the 
> mobile client, can the network make some proactive operation on 
> HTTP streaming? I'm not sure.
> > 
> Again, "not sure" isn't good enough. (I'm not sure if I might win 
> the lottery). I don't think we've even gotten to step (1), which 
> is demonstrating with real numbers and real measurements that 
> there is a problem to be solved here. Then we need step (2) which 
> is seeing if the problem has any feasible solutions that don't 
> break other things, or overcomplicate the architecture. Then we 
> can get to step (3) which is to compare the solutions against the 
> baseline of doing nothing. At that point if enough improvement is 
> demonstrated to warrant spending a lot of the IETF's time 
> standardizing something, we can work on the details.
> 
> My fear here is that we'll have a problem statement that boils 
> down to "we need nano fiber transport cables to geosynchronous 
> orbit" at one extreme, or "it sure would be nice if streaming HTTP 
> made better use of scarce radio resources on 4G networks" at the 
> other.
> I don't think the case has yet been made that there's a well-
> scoped problem for IETF to work on here. I heard somebody proposed 
> that perhaps an IRTF research group ought to be the first step. 
> That might be an alternative worth considering, but only if we can 
> get the right people actually doing work (i.e. researchers with 
> the right skill sets and resources to do the modeling, simulation, 
> and experiments).

Yes, all my messages here are very "raw" thought, so do not take it as argument for anything.

Regards,
Xiangsong

> 
> Cheers, DaveO.
> 
> 
> > Best Regards
> > Xiangsong
> > 
> > 
> > ----- 原邮件 -----
> > 发件人: David R Oran <oran@cisco.com>
> > 日期: 星期三, 十一月 10日, 2010 下午11:52
> > 主题: Re: [httpstreaming] Agenda and Slides
> > 收件人: Xiangsong Cui <Xiangsong.Cui@huawei.com>
> > 抄送: Mark Watson <watsonm@netflix.com>om>, httpstreaming 
> <httpstreaming@ietf.org>> 
> >> 
> >> On Nov 10, 2010, at 12:13 AM, Xiangsong Cui wrote:
> >> 
> >>> Hi,
> >>> 
> >>> I agree Kathy here.
> >>> And, Mark, yes, you are right, it drops packets. But this is 
> >> only a passive reaction, I think it is better to achieve some 
> >> active operation, or proactive operation (if possible), that 
> would 
> >> be perfact.
> >>> 
> >> Why? This is not at all obvious to some of us, unless by 
> >> "proactive" you mean turning on existing machinery that is not 
> yet 
> >> universally deployed, like RED and ECN. There is at least some 
> >> evidence that currently measured poor adaptive streaming 
> behaviors 
> >> can be explained by tail-drop routers hanging around all over 
> the 
> >> place. TCP is known to behave badly under heavy load with tail-
> >> drop queuing. I think you'd agree that it's a whole lot easier 
> to 
> >> turn on  well understood, standardized and nearly universally 
> >> implemented techniques at the network layer than it it is 
> stumble 
> >> around trying to invent new application and HTTP machinery to 
> try 
> >> to fake it out.
> >> 
> >> We also don't fully understand the effect of allowing adaptive 
> >> streaming clients to compete only against each other with no 
> cross 
> >> traffic present to inject enough noise to drive the adaptation 
> >> algorithms. The deployments today are without putting the 
> traffic 
> >> in a separate QoS class since they run over-the-top on BE 
> service. 
> >> It is far from clear that removing the cross-traffic induced 
> >> bandwidth variation will make things better - it might, counter-
> >> intuitively, make things worse!
> >> 
> >>> I think these jobs are worthy our attention.
> >>> 
> >> I do not think the case has yet been made, although I think 
> you'll 
> >> find we're all open minded and willing to listen.
> >> 
> >> With respect to the mobile environment specifically, there is 
> an 
> >> obvious space/time/computation/bandwidth tradeoff with respect 
> to 
> >> multi-rate coding (upon which adaptive HTTP streaming depends). 
> If 
> >> you only have a few rates to play with, it's obviously hard to 
> to 
> >> optimal bandwidth packing on radio channels that don't support 
> >> enough users to satisfy the "law of large numbers". It's even 
> >> harder to do it with good fairness properties. There are many 
> ways 
> >> to skin this cat though:
> >> 
> >> - spend the cycles on the encoders and space in the caches to 
> have 
> >> finer rate quantization in the multi-rate coding.
> >> - match the encoding rates to to the radio channel allocation 
> chunks>> - transrate a higher rate down to fit in the allocation 
> for a 
> >> given mobile user if that would result in better QoE than 
> shifting 
> >> them down to the next lower rate.
> >> 
> >> However, I'd like to observe that NONE of these techniques has 
> >> much (or at least very little) to do with the protocols and 
> >> algorithms for adaptive HTTP streaming.
> >> 
> >> There may be some small tweaks that one might do though. For 
> >> example, there might be useful transrating hints in server 
> >> manifests to tell streaming servers whether they are permitted 
> to 
> >> transrate a given profile, and hints in client manifests to 
> allow 
> >> them to request a transrate down as opposed to shifting to the 
> >> next lower coding rate. Alternatively, the manifests could just 
> >> lie about the number of profiles, and allow servers to 
> >> "synthesize" the intermediate profiles by transrating.
> >> 
> >> As a parting homily to those who think reservations and 
> admission 
> >> control are always superior to adaptation in their ability to 
> >> deliver QoE, remember that:
> >> 
> >> "The purpose of bandwidth reservation and admission control is 
> to 
> >> say NO, not to say YES". If you can always say YES, you don't 
> need 
> >> it, and if you say NO a lot, you are just quantizing unfairness 
> >> into a boolean."
> >> 
> >> DaveO.
> >> 
> >> 
> >> 
> >> 
> >>> Best Regards
> >>> Xiangsong
> >>> 
> >>> 
> >>> ----- 原邮件 -----
> >>> 发件人: Mark Watson <watsonm@netflix.com>
> >>> 日期: 星期三, 十一月 10日, 2010 下午12:24
> >>> 主题: Re: [httpstreaming] Agenda and Slides
> >>> 收件人: Kathy McEwen <kathy@iridescentnetworks.com>
> >>> 抄送: httpstreaming <httpstreaming@ietf.org>
> >>> 
> >>>> 
> >>>> 
> >>>> Sent from my iPad
> >>>> 
> >>>> On Nov 9, 2010, at 7:42 PM, "Kathy McEwen" 
> >>>> <kathy@iridescentnetworks.com> wrote:
> >>>> 
> >>>>> After doing some digging on the various
> >>>>> protocols (RTMP/http, RTSP, HTML5/http, etc... ), we found 
> >> that 
> >>>> all of them
> >>>>> that are doing any kind of adaptive rate streaming, but they 
> >> do 
> >>>> not today
> >>>>> incorporate the messages/control mechanisms to allow for the 
> >>>> network to take
> >>>>> control and adapt the rate of the video.
> >>>> 
> >>>> But it does! It drops packets, causing a congestion response 
> >> from 
> >>>> TCP causing in turn an adaptation by the application. The 
> >> network 
> >>>> is completely in control of the packet delivery rate, which 
> the 
> >>>> application knows and adapts to.
> >>>> 
> >>>> This is the baseline, which is so simple and applicable 
> across 
> >>>> myriad access technologies. New mechanisms need to justify 
> >>>> themselves against this baseline.
> >>>> 
> >>>> ...Mark 
> >>>> _______________________________________________
> >>>> httpstreaming mailing list
> >>>> httpstreaming@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/httpstreaming
> >>>> 
> >>> <c00111037.vcf>_______________________________________________
> >>> httpstreaming mailing list
> >>> httpstreaming@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/httpstreaming
> >> 
> >> 
> > <c00111037.vcf>
> 
>