Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal

Qin Wu <sunseawq@huawei.com> Mon, 18 October 2010 07:21 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 50F543A6CAE for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 00:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.817
X-Spam-Level:
X-Spam-Status: No, score=0.817 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 phiw8X2TtOvI for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 00:21:25 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 61D9A3A6C86 for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 00:21:25 -0700 (PDT)
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 <0LAH005L05TTZV@szxga04-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 15:22:42 +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 <0LAH00ELX5TT1Y@szxga04-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 15:22:41 +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 <0LAH000JL5TSWG@szxml06-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 15:22:41 +0800 (CST)
Date: Mon, 18 Oct 2010 15:22:38 +0800
From: Qin Wu <sunseawq@huawei.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Roni Even <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org>
Message-id: <03c001cb6e95$3edf86d0$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: text/plain; charset="windows-1252"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D6894A4@xmb-sjc-215.amer.cisco.com> <02d501cb6e87$9dc75dc0$30298a0a@china.huawei.com>
Cc: httpstreaming@ietf.org
Subject: Re: [httpstreaming] Push Vs Pull Re: 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: Mon, 18 Oct 2010 07:21:26 -0000

> How would this work if you have only one bitrate on the server? Is your approach as follows:
> 
> Rather than offering the same content encoded at multiple bitrates and serving them based on what the client wants, you
> wanna serve the content encoded at a single bitrate and by manipulating the transmission rate on the server (based on
> server's knowledge of network and client), you "adaptively" send it. Is that the scenario you have in mind?
> 
> [Qin]: Personally that is what I am trying to look for. a single birate for live content may change at time which can be
> realized by transcoding.

If you are saying a server doing transcoding for adaptation scales better than an http server serving client requests for different chunks, then I think you should make your arguments clear enough in the problem statement draft and see whether others think. To me, it is a losing proposition. 

[Qin]; for the live content consuming with thousands of consumers viewing at the same time, in my opinion, it may be a successful propsotion.

_______________________________________________
httpstreaming mailing list
httpstreaming@ietf.org
https://www.ietf.org/mailman/listinfo/httpstreaming