Re: [httpstreaming] Agenda and Slides

Kathy McEwen <kathy@iridescentnetworks.com> Thu, 11 November 2010 00:53 UTC

Return-Path: <kathy@iridescentnetworks.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 A11CD3A6811 for <httpstreaming@core3.amsl.com>; Wed, 10 Nov 2010 16:53:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 jWZAwSPvZ7MX for <httpstreaming@core3.amsl.com>; Wed, 10 Nov 2010 16:52:59 -0800 (PST)
Received: from smtp101-mob.biz.mail.gq1.yahoo.com (smtp101-mob.biz.mail.gq1.yahoo.com [98.136.185.192]) by core3.amsl.com (Postfix) with SMTP id 4CD763A67F2 for <httpstreaming@ietf.org>; Wed, 10 Nov 2010 16:52:59 -0800 (PST)
Received: (qmail 95123 invoked from network); 11 Nov 2010 00:53:22 -0000
Received: from [10.137.9.24] (kathy@166.205.139.182 with xymcookie) by smtp101-mob.biz.mail.gq1.yahoo.com with SMTP; 10 Nov 2010 16:53:18 -0800 PST
X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL
X-YMail-OSG: 2LwWdYEVM1ncRxbd15ENF4HSpw6hiL21OyIfmckydqW_7Oq VNj.ibN2_CnGLK5ChbD7ce4jFGg7GaDGd.X_PayQk0y_jePhkdx5ObYvJKnJ NJG_hXBoUEGUVgZXjHSTIhxCEb1xtLZU5Yg5cl0Tlyo9VlKix3vTZIW.1Fft FQw2jo7EjAdURPoH._yUTKjGufhKBl14prRhsqusmVlw5Jwhl0Gf9mCb1ACo iygoQQSZJ7FJZKXchXpRzHGRMKiQLazc7WkmK1RgVA8A6K2rUoMUjZ1v7TbB _1HANd6tgt5UAE.HRQfZ_7zVW4Og-
X-Yahoo-Newman-Property: ymail-3
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>
Mime-Version: 1.0 (iPhone Mail 8B117)
In-Reply-To: <20D6E2C9-8E84-42E8-8145-0AF0FE575AFE@cisco.com>
X-Apple-Yahoo-Original-Message-Folder: Inbox
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <D2E6084B-D918-478D-8EF8-46D5D47AAE58@iridescentnetworks.com>
From: Kathy McEwen <kathy@iridescentnetworks.com>
X-Apple-Yahoo-Replied-Msgid: 1_718885_ALLHjkQAALS8TNq/0QFtLmwTvpk
Date: Wed, 10 Nov 2010 16:31:57 -0800
To: David R Oran <oran@cisco.com>
X-Mailer: iPhone Mail (8B117)
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 00:53:01 -0000

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