Re: [httpstreaming] [dispatch] Q-HTTP

Kathy McEwen <kathy@iridescentnetworks.com> Wed, 10 November 2010 18:36 UTC

Return-Path: <kathy@iridescentnetworks.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 2F2AC3A69E2 for <httpstreaming@core3.amsl.com>; Wed, 10 Nov 2010 10:36:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 b7zcmovMp5dr for <httpstreaming@core3.amsl.com>; Wed, 10 Nov 2010 10:36:41 -0800 (PST)
Received: from smtp104-mob.biz.mail.ac4.yahoo.com (smtp104-mob.biz.mail.ac4.yahoo.com [76.13.13.225]) by core3.amsl.com (Postfix) with SMTP id 3B4563A69CF for <httpstreaming@ietf.org>; Wed, 10 Nov 2010 10:36:39 -0800 (PST)
Received: (qmail 66498 invoked from network); 10 Nov 2010 18:37:06 -0000
Received: from [10.9.85.23] (kathy@166.205.10.104 with xymcookie) by smtp104-mob.biz.mail.ac4.yahoo.com with SMTP; 10 Nov 2010 10:37:05 -0800 PST
X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL
X-YMail-OSG: tgF0cd8VM1mesochfWMlypN4ueiIzosLdb4VCg5CWjQXmXC dUsBcwDRc7XY_hY5yG9VPRwIbv0zhtudmzpfCh.S8UKq2RlVeUvckG4Ps2BW PCLn_4NApipRdSoQm34Y1LoA_bL2zdAPXPD0ldja4ApLJcx38zCruXLpaqVu nY7ZNBpZcgwuIHBl8Sa6moAUv1yH51xE4D.Igmkbqe7Rv3alDsFasAbQacad esJEGXj00UR0ZIJjU0ECpdZ5UNSFHIX3MypjHuK90ADtY0Lea9V_T1AoE1_A -
X-Yahoo-Newman-Property: ymail-3
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> <C4064AF1C9EC1F40868C033DB94958C7031F0CA2@XMB-RCD-111.cisco.com> <9426E357-5BCF-4D14-8FF2-867AE0BB77E5@apple.com> <C4064AF1C9EC1F40868C033DB94958C7031F0DD9@XMB-RCD-111.cisco.com>
Mime-Version: 1.0 (iPhone Mail 8B117)
In-Reply-To: <C4064AF1C9EC1F40868C033DB94958C7031F0DD9@XMB-RCD-111.cisco.com>
X-Apple-Yahoo-Original-Message-Folder: Inbox
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <C46947FB-10E1-4980-BD8F-7A2C6CA6FBB9@iridescentnetworks.com>
X-Mailer: iPhone Mail (8B117)
From: Kathy McEwen <kathy@iridescentnetworks.com>
X-Apple-Yahoo-Replied-Msgid: 1_723252_ALbHjkQAAKeCTNrj7whN4U94BfA
Date: Wed, 10 Nov 2010 10:36:09 -0800
To: "Mike Hammer \(hmmr\)" <hmmr@cisco.com>
Cc: "<dispatch@ietf.org>" <dispatch@ietf.org>, httpstreaming <httpstreaming@ietf.org>, "<conex@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 18:36:43 -0000

A scope that limits applications to only those that behave well seems extremely limiting.  What would you categorize as well behaved and naughty? 

Me, I tend to go for the naughty...

Sent from my iPhone

On Nov 10, 2010, at 10:26 AM, "Mike Hammer (hmmr)" <hmmr@cisco.com> wrote:

> David,
> 
> It is possible we have different usage scenarios in mind and could be
> talking past one another.  There are lots of variables.  Is this
> unicast, multicast, broadcast, full-duplex, interactive, mixtures of
> high and low BW, latency-sensitive and not, very bursty and not, where
> the sources of content are, how many sources, P2P or not, etc.  And all
> of these dynamically interact on the network.  Some subset of
> applications may be able to play nicely on a BE network.  But, I am just
> being cautions to not extrapolate that to all applications.  In some
> cases, the QoS may be worth the management and cost proportional to its
> usage.  So, maybe this is just an issue of scoping the application of
> the solution to the subset of traffic known to behave well.
> 
> Mike
> 
> 
> -----Original Message-----
> From: David Singer [mailto:singer@apple.com] 
> Sent: Wednesday, November 10, 2010 11:27 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
> 
> Mike
> 
> I'm not sure what you consider to be the primary model and what is the
> alternative.  Just in case we don't understand each other, I'll lay out
> where I think we are.
> 
> At the moment, we don't have QoS management, and HTTP streaming uses
> HTTP, which rests on TCP.  Applications don't "degrade themselves", they
> get degraded when contention happens, as a result of TCP's flow
> management, and have to cope.  It's a 'fair' system in that respect
> (especially when contrasted with RTP blast-and-hope).
> 
> In a QoS-managed scenario, something 'allows' me to indicate that a flow
> 'deserves' or 'needs' a certain QoS, including bandwidth, and then (if
> granted) I become immune to cross-traffic.  
> 
> For example, if all flows are equal, and initially there were 5 of which
> 2 are QoS managed, and they request only 10% of the resource, we're in
> great shape;  they get 20% and the 3 remaining share the remainder 60%,
> for 20% each.  But now 7 new flows come along, not QoS managed, so there
> are now 10 flows sharing that 60% for only 6% each, while the
> QoS-managed ones get 10% -- no longer fair.  If there isn't some
> disincentive to QoS-book bandwidth (like having to pay) we'll all set up
> the biggest channels we can.  If we *do* have to pay, the complexity of
> the QoS management is now increased -- not only handling the technical
> booking and reservation, segregation of packet flows, and so on, but it
> has a billing infrastructure too.
> 
> Then, in the case of QoS management, the service is probably only as
> strong as its weakest link.  Some QoS management protocols either set up
> an end-to-end QoS-managed flow (across potentially multiple providers)
> or they fail.  This doesn't allow for easy service introduction.
> Alternatively, they manage only some of the links, and then the
> QoS-booking becomes rather weak if the unmanaged link is the bottleneck.
> 
> Then there is the question of who sets up and who pays.  Imagine I (in
> california) try to watch a BBC video (from the UK).  It's me that needs
> to pay, but the BBC that needs to indicate to the service what pipe and
> QoS are needed to deliver their content.  Then all the business between
> me and them need to work out if they can do that QoS, and at what cost;
> someone needs to ask me if I am willing to pay, and if I agree, tell the
> BBC to setup the pipe, and off we go.  Contrast this with today where
> the BBC is careful not to use too much of its outbound pipe for one
> customer, and I buy the pipe I want, and each organization in the middle
> sells 'uplink' bandwidth.  That's a 'static' business arrangement.
> 
> On Nov 10, 2010, at 17:07 , Mike Hammer (hmmr) wrote:
> 
>> 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.
>> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
>