Re: [httpstreaming] [dispatch] Q-HTTP

Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Wed, 10 November 2010 06:54 UTC

Return-Path: <ben@niven-jenkins.co.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 019A13A69A4 for <httpstreaming@core3.amsl.com>; Tue, 9 Nov 2010 22:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.449
X-Spam-Level:
X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 aSoCcix6fBoG for <httpstreaming@core3.amsl.com>; Tue, 9 Nov 2010 22:54:06 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by core3.amsl.com (Postfix) with ESMTP id BB52F3A69A9 for <httpstreaming@ietf.org>; Tue, 9 Nov 2010 22:54:04 -0800 (PST)
Received: from dhcp-22dd.meeting.ietf.org ([130.129.34.221]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1PG4Zf-0002hm-JC; Wed, 10 Nov 2010 06:54:29 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
In-Reply-To: <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com>
Date: Wed, 10 Nov 2010 06:54:23 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <F095041D-E7F9-45E0-A741-7D231169CDF0@niven-jenkins.co.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> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com>
To: Mark Watson <watsonm@netflix.com>
X-Mailer: Apple Mail (2.1081)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: httpstreaming <httpstreaming@ietf.org>
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 06:54:11 -0000

[Trimmed to just httpstreaming list]

Mark,

On 10 Nov 2010, at 04:19, Mark Watson wrote:
> 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.
> 

It really depends what you mean by "QoS". As someone with experience of designing, deploying & managing both fixed-reservation network-based QoS as well as DiffServ based QoS at the UK's largest Broadband provider I would agree that in most cases fixed-reservation QoS is very expensive, inflexible and can be shown in a number of use cases to actually be detrimental to the User Experience (as viewed through the human eyeballs consuming the service).

However if by QoS one means "prioritisation against other traffic flows" then it can be a cost-effective way to provide a better User Experience to prioritised services but the lack of fixed reservation needs to be compensated for, and we have mechanisms to do that - e.g. for video one could use large playout buffers, adaptive technology[1], etc.

Avoiding scarcity is a reasonable approach but is not possible economically for some use cases/deployments - in those cases something else is needed but IMO (depending on the services being offered & the service[2] provider's business model) hard-QoS is not the answer but rather some combination of DiffServ and adaptive technologies.

But, overall I think we agree.

Ben

[1] "adaptive technology" in it's wider sense, not just HTTP Adaptive streaming
[2] by "service" provider I am including both network providers as well as providers that offer services (e.g. online video) to their users but may not own/operate the network infrastructure.




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