Re: [httpstreaming] Current Status and Our Goal

David R Oran <oran@cisco.com> Tue, 19 October 2010 17:45 UTC

Return-Path: <oran@cisco.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 E71E93A67C2 for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 10:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.301
X-Spam-Level:
X-Spam-Status: No, score=-110.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 6JyRN9IT3THf for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 10:45:31 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 23D903A67AB for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 10:45:31 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-Files: PGP.sig : 194
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAK52vUxAZnwN/2dsb2JhbAChaXGmcZxZhUoEikuDBA
X-IronPort-AV: E=Sophos; i="4.57,351,1283731200"; d="sig'?scan'208"; a="172582435"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2010 17:47:01 +0000
Received: from OranMBP.local (stealth-10-32-245-153.cisco.com [10.32.245.153]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9JHkf5I000491 for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 17:47:00 GMT
Received: from [127.0.0.1] by OranMBP.local (PGP Universal service); Tue, 19 Oct 2010 13:47:01 -0400
X-PGP-Universal: processed; by OranMBP.local on Tue, 19 Oct 2010 13:47:01 -0400
Mime-Version: 1.0 (Apple Message framework v1081)
From: David R Oran <oran@cisco.com>
X-Priority: 3
In-Reply-To: <62FF99A9-9B06-459F-87B4-416007E80983@csperkins.org>
Date: Tue, 19 Oct 2010 13:46:35 -0400
Message-Id: <51D0062B-D4D8-4495-8FC6-E50E5D67086E@cisco.com>
References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@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> <051901cb6c38$8b640f30$30 298a0a@china.huawei.com> <62FF99A9-9B06-459F-87B4-416007E80983@csperkins.org>
To: Colin Perkins <csp@csperkins.org>
X-Mailer: Apple Mail (2.1081)
X-PGP-Encoding-Format: MIME
X-PGP-Encoding-Version: 2.0.2
Content-Type: multipart/signed; boundary="PGP_Universal_367ADC9D_F21080C8_96AE7A95_453E1CBA"; protocol="application/pgp-signature"; micalg="pgp-sha1"
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: Tue, 19 Oct 2010 17:45:33 -0000

On Oct 19, 2010, at 1:16 PM, Colin Perkins wrote:

> On 15 Oct 2010, at 08:14, Qin Wu wrote:
>> ----- Original Message ----- 
>> From: "Ali C. Begen (abegen)" <abegen@cisco.com>
>> To: "Qin Wu" <sunseawq@huawei.com>; "Roni Even" <Even.roni@huawei.com>; "David A. Bryan" <dbryan@ethernot.org>
>> Cc: <httpstreaming@ietf.org>
>> Sent: Friday, October 15, 2010 1:14 PM
>> Subject: RE: [httpstreaming] Current Status and Our Goal
>> 
>> 
>>> But, in http streaming scenario, the ratio of download/upload (from the client's perspective) is much larger than 1. BTW, if you keep your chunk duration relatively longer, the amount of requests that you will end up sending will be almost nil compared to what you will receive.
>>> 
>>> [Qin]: No, I just compare pull and push with the same chunk duration.
>> 
>> You can choose whatever chunk size you wanna use. Does not matter. The fact remains the same. Unless someone uses chunks of a few hundreds of ms, it won't matter.
>> 
>> [Qin]: Suppose 10 chunks is available at the server side, in the pull model, the client need to send at least 10 requests and receive 10 responses. in the push model, the client may only need to send one request and then receive 10 responses. comparing with pull, push model save 9 requests. also if you look at websocket, push has more lightweight header than pull.
> 
> 
> This is true.  However, by changing to a push model, you also move the responsibility for maintaining state for rate adaptation to the server, rather than the client.  The extra state, and the complexity of running the rate adaptation algorithm, almost certainly outweighs the savings from reduced request processing.
> 
That is debatable. I personally side with Colin in such a debate, but there are people who do make credible arguments on the other side, and people who ship cost-effective and arguably scalable systems that work that way.

What I wonder is if the IETF is a productive venue to hold that debate. I suspect not.
The IETF never was able to stop IMS, and the ITU was never able to stop the Internet, hard as both tried.

Cheers, DaveO.


> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> httpstreaming mailing list
> httpstreaming@ietf.org
> https://www.ietf.org/mailman/listinfo/httpstreaming