Re: [httpstreaming] Agenda and Slides

"Ali C. Begen (abegen)" <abegen@cisco.com> Thu, 11 November 2010 08:18 UTC

Return-Path: <abegen@cisco.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 2A0093A67A4 for <httpstreaming@core3.amsl.com>; Thu, 11 Nov 2010 00:18:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.588
X-Spam-Level:
X-Spam-Status: No, score=-10.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 I+7uazmhs5eN for <httpstreaming@core3.amsl.com>; Thu, 11 Nov 2010 00:18:05 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EEC643A69BB for <httpstreaming@ietf.org>; Thu, 11 Nov 2010 00:18:04 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EADo220yrRN+K/2dsb2JhbACDOp4rWnGkJoozkQOBIoM1cwSEWokP
X-IronPort-AV: E=Sophos;i="4.59,181,1288569600"; d="scan'208";a="618066946"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2010 08:18:30 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id oAB8IUow026725; Thu, 11 Nov 2010 08:18:30 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 00:18:30 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Thu, 11 Nov 2010 00:17:43 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DA67557@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <D2E6084B-D918-478D-8EF8-46D5D47AAE58@iridescentnetworks.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [httpstreaming] Agenda and Slides
Thread-Index: AcuBOt5Ivs/rJ1aER+WOHM0yNJrKiAAPdNkQ
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> <D2E6084B-D918-478D-8EF8-46D5D47AAE58@iridescentnetworks.com>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "Kathy McEwen" <kathy@iridescentnetworks.com>, "Dave Oran (oran)" <oran@cisco.com>
X-OriginalArrivalTime: 11 Nov 2010 08:18:30.0185 (UTC) FILETIME=[05FF8990:01CB8179]
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: Thu, 11 Nov 2010 08:18:06 -0000

Can 2g provide acceptable video quality anyway even if everything is close to be perfect? During such a handoff, many things will probably fail to work... it certainly won't be that seamless to the client.

-acbegen

> -----Original Message-----
> From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Kathy McEwen
> Sent: Thursday, November 11, 2010 8:32 AM
> To: Dave Oran (oran)
> Cc: httpstreaming
> Subject: Re: [httpstreaming] Agenda and Slides
> 
> How about the mobile handoff scenario from 3G to 2g where the 2g has only ATM backhaul from the radio, no TCP
> interaction.  .... How does the network and the handset use adaptive rate encoding, http and tcp then?
> 
> Sent from my iPhone
> 
> On Nov 10, 2010, at 7:52 AM, David R Oran <oran@cisco.com> wrote:
> 
> >
> > 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
> >
> > _______________________________________________
> > 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