Re: [httpstreaming] [dispatch] Q-HTTP

"Mike Hammer (hmmr)" <hmmr@cisco.com> Wed, 10 November 2010 15:04 UTC

Return-Path: <hmmr@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 A928A3A69DE; Wed, 10 Nov 2010 07:04:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.449
X-Spam-Level:
X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 AglCFVVZUJv9; Wed, 10 Nov 2010 07:04:36 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2FEBD3A6851; Wed, 10 Nov 2010 07:04:36 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAC9D2kytJXG8/2dsb2JhbACiNXGiQJsshUoEhFqJDw
X-IronPort-AV: E=Sophos;i="4.59,178,1288569600"; d="scan'208";a="180623895"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rtp-iport-2.cisco.com with ESMTP; 10 Nov 2010 15:05:02 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id oAAF52sh004094; Wed, 10 Nov 2010 15:05:02 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 09:05:02 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 10 Nov 2010 09:05:01 -0600
Message-ID: <C4064AF1C9EC1F40868C033DB94958C7031F0C1F@XMB-RCD-111.cisco.com>
In-Reply-To: <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dispatch] [httpstreaming] Q-HTTP
Thread-Index: AcuAjmy2DbYTXxLsQwO+PWlAAVcPSgAWTnVg
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><01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com>
From: "Mike Hammer (hmmr)" <hmmr@cisco.com>
To: "Mark Watson" <watsonm@netflix.com>, "Kathy McEwen" <kathy@iridescentnetworks.com>
X-OriginalArrivalTime: 10 Nov 2010 15:05:02.0541 (UTC) FILETIME=[A68FEFD0:01CB80E8]
X-Mailman-Approved-At: Tue, 16 Nov 2010 08:29:25 -0800
Cc: dispatch@ietf.org, httpstreaming <httpstreaming@ietf.org>, conex@ietf.org, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" <jose_javier.garcia_aranda@alcatel-lucent.com>
Subject: Re: [httpstreaming] [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 15:04:37 -0000

Nice theory.  Until it gets down to who is going to pay for the
over-provisioning.

Is the ARPU going to go up?  Are content distributors willing to pay
more to send that data?

Also, note how the volume of traffic always seems to expand to fill the
BW available.

Mike


-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Mark Watson
Sent: Tuesday, November 09, 2010 11:19 PM
To: Kathy McEwen
Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson
S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER)
Subject: Re: [dispatch] [httpstreaming] Q-HTTP



Sent from my iPad

On Nov 9, 2010, at 7:01 PM, "Kathy McEwen"
<kathy@iridescentnetworks.com> wrote:

> One problem with the voice analogy is that the sheer volume of data
> traversing the web today is not driven by voice...it's video...and
it's not
> even a fraction of the viewing that folks are doing of broadcast
content.  A
> solution that depends on "simply" having too much bandwidth, is that
someone
> is paying for it.  Eventually it hits someone's pocket books....and if
there
> isn't sufficient revenue to cover the costs, the too much does
degrade.
> Today the mass media is consumed via cheap broadcast technologies...
why
> shouldn't the web (fixed and mobile) be as cheap AND as good??  
> 

It should, the question is what is the cheapest way to do it. QoS is
expensive too. I tend to agree with the thesis below that history is
telling us that avoiding scarcity in the first place is cheaper than
rationing here.

...Mark

> -----Original Message-----
> From: httpstreaming-bounces@ietf.org
[mailto:httpstreaming-bounces@ietf.org]
> On Behalf Of Lars Eggert
> Sent: Tuesday, November 09, 2010 8:02 PM
> To: David Singer
> Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER);
> httpstreaming; dispatch@ietf.org; conex@ietf.org
> Subject: Re: [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
> 
> _______________________________________________
> httpstreaming mailing list
> httpstreaming@ietf.org
> https://www.ietf.org/mailman/listinfo/httpstreaming
> 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch