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

"Mcdysan, David E" <dave.mcdysan@verizon.com> Wed, 10 November 2010 02:34 UTC

Return-Path: <dave.mcdysan@verizon.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 564813A657C; Tue, 9 Nov 2010 18:34:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24]
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 qXBq9UrqJYtD; Tue, 9 Nov 2010 18:34:23 -0800 (PST)
Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 2B4553A6403; Tue, 9 Nov 2010 18:34:23 -0800 (PST)
Received: from irvintrmemf1.verizon.com (irvintrmemf1.verizon.com [138.83.34.101]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id oAA2YZci021748; Tue, 9 Nov 2010 21:34:36 -0500 (EST)
X-AuditID: 8a532265-b7baeae00000194c-b7-4cda04bb689d
Received: from smtptpa3.verizon.com ( [138.83.71.176]) by irvintrmemf1.verizon.com (Symantec Brightmail Gateway) with SMTP id 9D.32.06476.BB40ADC4; Tue, 9 Nov 2010 20:34:35 -0600 (CST)
Received: from FHDP1LUMXC7HB02.us.one.verizon.com (fhdp1lumxc7hb02.verizon.com [166.68.59.189]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id oAA2YYc8009224; Tue, 9 Nov 2010 21:34:34 -0500 (EST)
Received: from fhdp1lumxc7v11.us.one.verizon.com ([fe80::4c3d:3366:54ab:8118]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Tue, 9 Nov 2010 21:34:34 -0500
From: "Mcdysan, David E" <dave.mcdysan@verizon.com>
To: Lars Eggert <lars.eggert@nokia.com>, David Singer <singer@apple.com>
Date: Tue, 9 Nov 2010 21:34:33 -0500
Thread-Topic: [conex] [httpstreaming] [dispatch] Q-HTTP
Thread-Index: AcuAe2a3CyErCb4sQgG6KW17+mum5gAAozUL
Message-ID: <2464076D83FAED4D985BF2622111AAC40F95CCF86C@FHDP1LUMXC7V11.us.one.verizon.com>
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>
In-Reply-To: <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Tue, 16 Nov 2010 08:29:25 -0800
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" <jose_javier.garcia_aranda@alcatel-lucent.com>, httpstreaming <httpstreaming@ietf.org>, "dispatch@ietf.org" <dispatch@ietf.org>, "conex@ietf.org" <conex@ietf.org>
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:34:23 -0000

Lars,

Thanks for sharing this post and reference.

I try to make a similar point in section 4.3 of http://tools.ietf.org/id/draft-mcdysan-conex-other-usecases-00.txt

Some operators provision sufficient capacity at bottleneck points and/or make productive use of restoration capacity so that congestion rarely occurs. A much larger potential benefit than that offered by short term congestion control occurs if a means to motivate time shifting of traffic to off-peak periods can be developed.

Thanks,

Dave

________________________________________
From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of Lars Eggert [lars.eggert@nokia.com]
Sent: Tuesday, November 09, 2010 9:02 PM
To: David Singer
Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); httpstreaming; dispatch@ietf.org; conex@ietf.org
Subject: Re: [conex] [httpstreaming] [dispatch]   Q-HTTP

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