IETF Logo Mail Archive

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

Thomas Stockhammer <stockhammer@nomor.de> Mon, 18 October 2010 07:56 UTC

Return-Path: <stockhammer@nomor.de>
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 B26B43A6CB0 for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 00:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.416
X-Spam-Level:
X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 MD8JvpEhmjhu for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 00:56:58 -0700 (PDT)
Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id AD1103A67AD for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 00:56:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1287388704; l=2170; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=nnzRH/IMmejOno2pvRLoC3RPdIc=; b=r/E6Wa2Q5wYUszI/E0hBEiSDU/zNq9gCRRFR7YRAyQZzdeTDQFPMOxlJ4k4v1tHYUpC bzsLqiy7C4i6vxk7A8v4LLnyCUOaq12h8pq/u8dHCBj3knedzNTGyGZ6PDhLo+vCGizc8 +g7hMg6bOEjfyfUKI4C9vB0F5J+AVOZUjn4=
X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+0wBefkJA5cHz4sK4A==
X-RZG-CLASS-ID: mo00
Received: from [172.16.1.2] (91-67-202-136-dynip.superkabel.de [91.67.202.136]) by post.strato.de (klopstock mo35) (RZmta 23.5) with ESMTP id a06e60m9I7ltac ; Mon, 18 Oct 2010 09:58:24 +0200 (MEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=windows-1252
From: Thomas Stockhammer <stockhammer@nomor.de>
X-Priority: 3
In-Reply-To: <03f101cb6e97$f582acd0$30298a0a@china.huawei.com>
Date: Mon, 18 Oct 2010 09:58:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F06A5E53-C615-40FE-BE9E-F13AADAAD13A@nomor.de>
References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.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> <03c001cb6e95$3edf86d0$30298a0a@china.huawei.com> <03f101cb6e97$f582acd0$30298a0a@china.huawei.com>
To: Qin Wu <sunseawq@huawei.com>
X-Mailer: Apple Mail (2.1081)
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:56:59 -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.
> 
> [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] 

---
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.

v2.8.7 | Report a Bug | By Email