Re: [httpstreaming] [dispatch] Q-HTTP

David Singer <singer@apple.com> Wed, 10 November 2010 15:24 UTC

Return-Path: <singer@apple.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 CBC0E3A69F6; Wed, 10 Nov 2010 07:24:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.562
X-Spam-Level:
X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 hf1iRR79eeCy; Wed, 10 Nov 2010 07:24:50 -0800 (PST)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 85C0E3A696B; Wed, 10 Nov 2010 07:24:50 -0800 (PST)
Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id D8808B62733F; Wed, 10 Nov 2010 07:25:17 -0800 (PST)
X-AuditID: 11807136-b7b3aae0000033cc-94-4cdab946272b
Received: from [17.72.145.142] (Unknown_Domain [17.72.145.142]) by relay15.apple.com (Apple SCV relay) with SMTP id 9E.93.13260.B49BADC4; Wed, 10 Nov 2010 07:25:17 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: David Singer <singer@apple.com>
In-Reply-To: <C4064AF1C9EC1F40868C033DB94958C7031F0C1F@XMB-RCD-111.cisco.com>
Date: Wed, 10 Nov 2010 16:24:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <EF84DC37-8CB6-4DB7-85AC-E091D90FF075@apple.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> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <C4064AF1C9EC1F40868C033DB94958C7031F0C1F@XMB-RCD-111.cisco.com>
To: "Mike Hammer (hmmr)" <hmmr@cisco.com>
X-Mailer: Apple Mail (2.1081)
X-Brightmail-Tracker: AAAAAA==
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:24:51 -0000

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.