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

Qin Wu <sunseawq@huawei.com> Mon, 18 October 2010 08:14 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 557F33A6CD9 for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 01:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.335
X-Spam-Level: **
X-Spam-Status: No, score=2.335 tagged_above=-999 required=5 tests=[AWL=-1.652, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315]
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 n2T5hSJHk4nl for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 01:14:02 -0700 (PDT)
Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5D9143A6C58 for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 01:13:47 -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 <0LAH007G6877EA@szxga05-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 16:13:55 +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 <0LAH00JBM87633@szxga05-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 16:13:54 +0800 (CST)
Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAH0067R876XQ@szxml04-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 16:13:54 +0800 (CST)
Date: Mon, 18 Oct 2010 16:13:52 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Thomas Stockhammer <stockhammer@nomor.de>
Message-id: <043601cb6e9c$6719f8e0$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: base64
X-Priority: 3
X-MSMail-priority: Normal
iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated.
References: <00df01cb5de2$2ac49730$4f548a0a@china.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> <03c001cb6e95$3edf86d0$30298a0a@china.huawei.com> <03f101cb6e97$f582acd0$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 08:15:01 -0000

----- Original Message ----- 
From: "Thomas Stockhammer" <stockhammer@nomor.de>
To: "Qin Wu" <sunseawq@huawei.com>
Cc: "Ali C. Begen (abegen)" <abegen@cisco.com>; "Roni Even" <Even.roni@huawei.com>; "David A. Bryan" <dbryan@ethernot.org>; <httpstreaming@ietf.org>
Sent: Monday, October 18, 2010 3:58 PM
Subject: Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal


>>> 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.
> 
> [T] Adaptation for each of the thousands of users!?  [\T]
> 
> [Qin]: The scenario we are talking about is more and more people watching one popuar global event at the same time, e.g., world cup finals, US president election, Olympic games.


[T] 
Exactly! And therefore individual server side adaptation is worst ... 
To maintain a 1-1 relationship between the client and the server breaks scalability. 
Just offer a couple of bitrate choices and the millions of clients will pick the one that suits them. Clients are extremely intelligent and capable nowadays. 
Network-initiated individual QoS control is not a subject in HTTP streaming. 
[\T] 

[Qin]: It seems you talk about server based solution in your vision which I can't follow. In my understanding, client based solution more fit for recorded content consuming than live content consuming.
The big problem of current existing client based solution can not well satisfy real time streaming requirements during live content consuming.

---
Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.