Re: [httpstreaming] [conex] [dispatch] Q-HTTP

ken carlberg <carlberg@g11.org.uk> Wed, 10 November 2010 02:24 UTC

Return-Path: <carlberg@g11.org.uk>
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 2B43D3A6902; Tue, 9 Nov 2010 18:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 rZEnfLWwqYZX; Tue, 9 Nov 2010 18:24:33 -0800 (PST)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id E75A33A684C; Tue, 9 Nov 2010 18:24:32 -0800 (PST)
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:51905 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from <carlberg@g11.org.uk>) id 1PG0Ml-0003bF-3l; Wed, 10 Nov 2010 02:24:51 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: ken carlberg <carlberg@g11.org.uk>
In-Reply-To: <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com>
Date: Tue, 9 Nov 2010 21:24:50 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <7AB4E81D-48F9-4E7B-B6F4-CFFBB4C452F1@g11.org.uk>
References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <DBB1DC060375D147AC43F310AD987DCC180E504600@ESESSCMS0366.eemea.ericsson.se> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <EAA2CFBF-9434-4E52-A586-7AE5F665A9DF@apple.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com>
To: Lars Eggert <lars.eggert@nokia.com>
X-Mailer: Apple Mail (2.1081)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Source:
X-Source-Args:
X-Source-Dir:
X-Mailman-Approved-At: Tue, 16 Nov 2010 08:29:25 -0800
Cc: "dispatch@ietf.org" <dispatch@ietf.org>, httpstreaming <httpstreaming@ietf.org>, "conex@ietf.org" <conex@ietf.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" <jose_javier.garcia_aranda@alcatel-lucent.com>
Subject: Re: [httpstreaming] [conex] [dispatch] Q-HTTP
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, 10 Nov 2010 02:24:35 -0000

I would agree with Dave Singer's points below, but with significant qualifiers.  VoIP is being used more and more because significant pockets of acceptable quality can be found, but these are subject to location, and at times, time of day usage (eg, my use of Skype versus POTS varies depending on where I make my calls to Chile).  And as you get closer to the last mile (wireless and the backhaul in particular), economics do play more of a factor in how much reliance over-provisioning can solve all problems.

-ken

ps, I'm only on conex mailing list, so this will probably bounce on dispatch and httpstreaming


On Nov 9, 2010, at 9:02 PM, Lars Eggert wrote:

> On 2010-11-9, at 18:31, David Singer wrote:
>> It is that there are two ways to solve a real-time bandwidth need.  One is to reserve bandwidth, manage QoS and so on;  one gets protocols and systems like diffserv, ATM, and so on.  The other is simply to have 'too much' of the resource.  Though it feels wrong, the latter often ends up being the cheaper and easier solution.  So, for example, voice over IP is getting used quite a lot, and to good effect, on the internet today not because we have successfully deployed any bandwidth reservation or QoS management protocols and systems, but because the available bandwidth is, for the most part, greatly in excess of what is needed, and the systems can adapt in real-time to what they get (rather than asking for what they want).  The same is true for multimedia delivery;  the complexity of RTP + TCP friendliness + QoS management is not worth it compared to having adaptable end-systems and overall more bandwidth than needed.
> 
> Fully agreed. 
> 
> Folks who like pictures can take a look at https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much the same argument.
> 
> Lars_______________________________________________
> conex mailing list
> conex@ietf.org
> https://www.ietf.org/mailman/listinfo/conex