Re: [httpstreaming] Current Status and Our Goal

Ning Zong <zongning@huawei.com> Wed, 20 October 2010 09:44 UTC

Return-Path: <zongning@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 18E4F3A63CB for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 02:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.811
X-Spam-Level:
X-Spam-Status: No, score=-99.811 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 63j1uH2DtPOB for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 02:44:46 -0700 (PDT)
Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9F3F43A6359 for <httpstreaming@ietf.org>; Wed, 20 Oct 2010 02:44:46 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAL00BDX1SWBZ@szxga05-in.huawei.com> for httpstreaming@ietf.org; Wed, 20 Oct 2010 17:46:09 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAL00CHG1SV69@szxga05-in.huawei.com> for httpstreaming@ietf.org; Wed, 20 Oct 2010 17:46:08 +0800 (CST)
Received: from z63316 ([10.138.41.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAL007T41SUKU@szxml04-in.huawei.com> for httpstreaming@ietf.org; Wed, 20 Oct 2010 17:46:07 +0800 (CST)
Date: Wed, 20 Oct 2010 17:46:06 +0800
From: Ning Zong <zongning@huawei.com>
In-reply-to: <009e01cb7033$c0607120$3a298a0a@china.huawei.com>
To: 'Ning Zong' <zongning@huawei.com>, "'Ali C. Begen (abegen)'" <abegen@cisco.com>, 'Roni Even' <Even.roni@huawei.com>, "'David A. Bryan'" <dbryan@ethernot.org>, 'Qin Wu' <sunseawq@huawei.com>
Message-id: <00b101cb703b$9e5827f0$3a298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: ActgCGuD1NnF29rfRjaXK8fG462/2gFlt4PwAAEVLUACo40kUAACaL4w
Cc: httpstreaming@ietf.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: Wed, 20 Oct 2010 09:44:48 -0000

Sorry, to be clear, the FCC concern I consider here is limited to live
streaming scenario.

-----Original Message-----
From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org]
On Behalf Of Ning Zong
Sent: Wednesday, October 20, 2010 4:50 PM
To: 'Ali C. Begen (abegen)'; 'Roni Even'; 'David A. Bryan'; 'Qin Wu'
Cc: httpstreaming@ietf.org
Subject: Re: [httpstreaming] Current Status and Our Goal

IMO, the issue may not only related to multicast or unicast, but the QoE
improvement (e.g. reduce the startup time after user change the channel). If
I remember correctly, in the motivation of FCC in AVT, one important concern
is that the Retransmission server can store the most recent GoPs and feed
them to the client with faster rate than playback to effectively fill the
gap between the time point of user channel zapping and next complete GoP.
This improvement also applies to unicast based HTTP streaming, right?
The above concern also implies that adding some intelligence to
intermediaries would improve the streaming performance of HTTP streaming
system. To be more specific, having a deep look at the mechanisms of
distinguish different types of HTTP traffic (e.g. live streaming with higher
timing requirement v.s. normal packet, streaming packet containing I-frame
worthy of caching for further usage v.s. normal streaming packet) would be a
possible direction for consideration in this list.

My two cents.

BR,
Ning Zong

-----Original Message-----
From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org]
On Behalf Of Ali C. Begen (abegen)
Sent: Thursday, October 07, 2010 6:15 AM
To: Roni Even; David A. Bryan; Qin Wu
Cc: httpstreaming@ietf.org
Subject: Re: [httpstreaming] Current Status and Our Goal

> 2. Address the startup issue, we have worked in AVT on fast
channel/content
> change and I think this is relevant also in this case.

Are you assuming a multicast environment for http streaming? Ow, the startup
issue is not an issue in unicast connections.

-acbegen
_______________________________________________
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