Re: [httpstreaming] [dispatch] Q-HTTP

"Mike Hammer (hmmr)" <hmmr@cisco.com> Wed, 10 November 2010 16:07 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 D9B4028C0D8; Wed, 10 Nov 2010 08:07:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.499
X-Spam-Level:
X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 hNkCyWoTEQgo; Wed, 10 Nov 2010 08:07:02 -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 B738B3A6A49; Wed, 10 Nov 2010 08:07:01 -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: AvsEAD9R2kytJXG//2dsb2JhbACiNXGiX5sxhUoEhFqJDw
X-IronPort-AV: E=Sophos;i="4.59,178,1288569600"; d="scan'208";a="180663741"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rtp-iport-2.cisco.com with ESMTP; 10 Nov 2010 16:07:28 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id oAAG7S9U010925; Wed, 10 Nov 2010 16:07:28 GMT
Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 10:07:28 -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 10:07:26 -0600
Message-ID: <C4064AF1C9EC1F40868C033DB94958C7031F0CA2@XMB-RCD-111.cisco.com>
In-Reply-To: <EF84DC37-8CB6-4DB7-85AC-E091D90FF075@apple.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dispatch] [httpstreaming] Q-HTTP
Thread-Index: AcuA635tZrZtFBYVRyKsZzNajgoYqQAA6wfQ
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> <C4064AF1C9EC1F40868C033DB94958C7031F0C1F@XMB-RCD-111.cisco.com> <EF84DC37-8CB6-4DB7-85AC-E091D90FF075@apple.com>
From: "Mike Hammer (hmmr)" <hmmr@cisco.com>
To: David Singer <singer@apple.com>
X-OriginalArrivalTime: 10 Nov 2010 16:07:28.0382 (UTC) FILETIME=[5F41E9E0:01CB80F1]
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 16:07:04 -0000

My problem is that the alternative solution proposes that:

1) Users will police themselves and degrade their experience for the
good of the Internet, and
2) Somehow high-BW bursty applications will become non-bursty.
3) The people that build and operate the networks will double
(quadruple?) their investments for no additional return out of the
goodness of their hearts.

Somehow this reminds me of Gates prognostication that 640K was all the
memory that a PC would ever need.

I'm sympathetic with having a simple answer, but I just haven't seen
that happen in the last 30 years.

Don't forget that for some time we have had QoS managed and paid for.  
The burden of proof then lies in proving the new economic model works.
Good luck.  I will be the first to congratulate you if you do.

Cheers,
Mike


-----Original Message-----
From: David Singer [mailto:singer@apple.com] 
Sent: Wednesday, November 10, 2010 10:25 AM
To: Mike Hammer (hmmr)
Cc: Mark Watson; Kathy McEwen; dispatch@ietf.org; httpstreaming;
conex@ietf.org; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA,
JOSEJAVIER (JOSE JAVIER)
Subject: Re: [dispatch] [httpstreaming] Q-HTTP


On Nov 10, 2010, at 16:05 , Mike Hammer (hmmr) wrote:

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

Well, it's a nice theory until someone asks who is going to (a) pay for
the QoS management infrastructure and (b) pay for the QoS managed
traffic.

> 
> 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
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

David Singer
Multimedia and Software Standards, Apple Inc.