Re: [httpstreaming] [conex] [dispatch] Q-HTTP

Kevin Mason <Kevin.Mason@telecom.co.nz> Mon, 15 November 2010 04:23 UTC

Return-Path: <prvs=59356E9B4C=Kevin.Mason@telecom.co.nz>
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 A38C53A63CB; Sun, 14 Nov 2010 20:23:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1]
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 0VBMWmguSLcR; Sun, 14 Nov 2010 20:23:43 -0800 (PST)
Received: from mgate1.telecom.co.nz (envoy-out.telecom.co.nz [146.171.15.100]) by core3.amsl.com (Postfix) with ESMTP id CCE963A693A; Sun, 14 Nov 2010 20:23:42 -0800 (PST)
Received: from mgate6.telecom.co.nz (unknown [146.171.1.21]) by mgate1.telecom.co.nz (Postfix) with ESMTP id 1A0C57B4AB4; Mon, 15 Nov 2010 17:24:21 +1300 (NZDT)
X-WSS-ID: 0LBWS8J-09-2OV-02
X-M-MSG:
Received: from hp2847.telecom.tcnz.net (hp2847.telecom.tcnz.net [146.171.228.249]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mgate6.telecom.co.nz (Postfix) with ESMTP id 1537D5DAD5CC; Mon, 15 Nov 2010 17:24:19 +1300 (NZDT)
Received: from hp3120.telecom.tcnz.net (146.171.212.205) by hp2847.telecom.tcnz.net (146.171.228.249) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 15 Nov 2010 17:24:20 +1300
Received: from WNEXMBX01.telecom.tcnz.net ([146.171.212.201]) by hp3120.telecom.tcnz.net ([146.171.212.205]) with mapi; Mon, 15 Nov 2010 17:24:20 +1300
From: Kevin Mason <Kevin.Mason@telecom.co.nz>
To: "conex@ietf.org" <conex@ietf.org>
Date: Mon, 15 Nov 2010 17:24:19 +1300
Thread-Topic: [conex] [dispatch] [httpstreaming] Q-HTTP
Thread-Index: AcuB0uVHZzrj+JIgQaK7yQuY6NMMfQADQk1wAJeuE9A=
Message-ID: <9BC62293D3D9534AACB0FEC5F2DE51B20130E801@WNEXMBX01.telecom.tcnz.net>
References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <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> <alpine.DEB.1.10.1011102303170.2639@uplift.swm.pp.se> <C4064AF1C9EC1F40868C033DB94958C7031F10D0@XMB-RCD-111.cisco.com> <alpine.DEB.1.10.1011111616310.2639@uplift.swm.pp.se> <C4064AF1C9EC1F40868C033DB94958C7031F1154@XMB-RCD-111.cisco.com> <alpine.DEB.1.10.1011111806430.2639@uplift.swm.pp.se> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <alpine.DEB.1.10.1011111957580.2639@uplift.swm.pp.se> <002a01cb81e1$40e58740$c2b095c0$@com>
In-Reply-To: <002a01cb81e1$40e58740$c2b095c0$@com>
Accept-Language: en-US, en-NZ
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-NZ
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 16 Nov 2010 08:29:25 -0800
Cc: 'httpstreaming' <httpstreaming@ietf.org>, "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [httpstreaming] [conex] [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: Mon, 15 Nov 2010 04:23:50 -0000

I think much of this discussion is missing the root issue.

For any communication there is a source and sink. If the communication needs to pass information in both directions (other then underlying flow management) then each end becomes both a source and a sink. 

The path used for this communication is whatever is available. An ISP can influence where the source of anything a sink wish's to receive is, but commercial and regulatory models can impact beyond what an ISP can control.

As a very general rule, distance costs. There are exceptions but the longer the path generally the higher the cost. As an ISP on the opposite of the world to the majority of the English speaking populations this is more apparent to us that others!

To suggest that the global industry should or even could ensure that no congestion ever occurs between any source and any sink (i.e. the "core") is a little unrealistic. The probability of congestion on any path is never zero, regardless of how over provisioned it is. A forwarding link is always 100% utilised while it is forwarding a packet, so irrespective of the speed of the link and frequency of arrival of packets for onward transmission, if another packet arrives while the previous one is being sent then it has to wait. So how long does it have to wait before the link is considered "congested".

How long a packet might have to wait is determined by the ISP in its queue management and cpacity management at any forwarding point. However the ISP has no idea what the role of that packet is in the application the source and sink are exchanging data for, only the users do.

So the issue re congestion is not if congestion occurs, but how frequency, and how much delay (or loss) can each application tolerate before its value or utility to the source and sink diminishes. Telephony (and ATM) has a reservation mechanism built in, but there is still an "engineered" probability that congestion occurs and the reservation cannot be made.

So sources and sinks between them have options. 

One option discussed in this thread at length is that the application is, or could be, in some way elastic. But even this elasticity does not always come for free, the application has to build that in (clever codecs have royalties, as does processing power for user equipment to do any required computation at an acceptable rate), and the users may have to be willing to forgo some of the potential richness of their application when path bottlenecks occur. If this is acceptable, application elasticity can be effective in creating a more acceptable outcome more often for the total population of sources and sink combinations. 

Elasticity is not just a function of the application, albeit some applications tend to lend themselves to elastic behaviour more than others, but elasticity is more a function of what the source and sink are doing at the time, and is in part determined by what incentives service provider's put in place to encourage users to implement and/or enable elasticity in application behaviour. As has already been mentioned, the threshold when path conditions reach a point that begins to degrade the experience, regardless of application elasticity, is very low for some uses (e.g. FPS games).

The bandwidth for "acceptable" human speech conversation (telephony) is becoming trivial in relation to bandwidth required for other uses (e.g. HD video). So if any degree of fairness exists on paths, the probability that an acceptable path will exist for the duration of any source and sink speech path combination is getting higher by the day. So value for any differential mechanism for improving speech path performance probability (reservations, prioritisation) is rapidly diminishing except on paths where bandwidth remains expensive (e.g. wireless access) because of the scarcity of radio spectrum.

ISPs have a common problem, like any transport provider, in managing incentives (financial or market imposed) to discourage undue concentration of popular sources, and/or concentration of popular sinks, and to manage the balance between an individual's appetite to consume resources when it is most convenient to them (and therefore a high probability it is the most convenient time for the majority of other like users), verses modifying their behaviour (e.g. reducing consumption rate or shifting their consumption to periods of lower utilisation). Zero congestion can never be achieved. But the probability might remain very very low in most cases if providing excess capacity remains more efficient on the majority of paths rather than managing fair sharing of the resources. [art of the challenge is to give realistic expectation on what sources and sinks can reasonably expect using language they can understand.

So tools like LEDBAT, the proposed Q-HTTP, ECN, are all mechanisms to enable individuals (or their applications on their behalf) to identify when the path transfer function may be falling below a desired threshold for the preferred mode of application operation, and therefore enable users to change their behaviour if they are willing to (or to hope other users will change their behaviour first and leave space for them!). But there is little or no reward for this concession, so many will continue to just complain. These mechanisms do not inherently provide the provider with information that would enable the provider to intervene and referee who gets what if its considered to be getting too unfair. 

CONEX on the other hand is trying, as I understand it, to provide real time information to providers that would better enable providers to referee who get what if user (or upstream providers as the agent for upstream sources) on their own do not all play fairly, if providers choose to use the information in this way.



Cheers
Kevin Mason
> -----Original Message-----
> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of
> Toby Moncaster
> Sent: Friday, 12 November 2010 9:45 a.m.
> To: conex@ietf.org
> Cc: 'httpstreaming'; dispatch@ietf.org
> Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP
> 
> > -----Original Message-----
> > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf
> > Of Mikael Abrahamsson
> > Sent: 11 November 2010 19:02
> > To: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)
> > Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson
> > S; Kathy McEwen; Mike Hammer (hmmr); GARCIA ARANDA, JOSE JAVIER (JOSE
> > JAVIER)
> > Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP
> >
> >
> > > - Enables network operators to generate more revenue for
> > > "over-requirements". I dont think real-time was in mind whe Internet
> > was
> > > created and we need to provide ISPs with new tools like this.
> >
> > "over-requirement" as in "I want to actually get what you promised to
> > deliver to me"?
> >
> > I don't buy it.
> 
> Mikael - I think you already put your finger on the problem when you
> pointed
> out that in your country ISPs are obliged to only promise customers what
> they can reasonably deliver. In most of the world ISPs are still marketing
> "Up to 8 Mbps" or "Up to 20Mbps" for services that at peak, for ~10% of
> customers can manage ~6.5Mbps and 18Mbps respectively, with most customers
> getting half that, and where the backhaul capacity is 10s of kbps per user
> (contention ratios of ~100 to 1).
> 
> What has gone wrong for ISP business models is that the world has changed,
> with streaming and interactive services overtaking bulk transfer and web
> browsing. ConEx may at times appear to be operator centric, but in many
> places it is the customers that are suffering because ISPs are forced to
> use
> pretty crude mechanisms to try and control the small percentage of heavy
> users. Clearly everyone must benefit if background bulk data transfers
> move
> to something like LEDBAT? But currently the operators treat that just the
> same as any other P2P traffic so no-one benefits.
> 
> There is also the issue of fair allocation of upgrades. Obviously if an
> ISP
> spends a lot of money on increasing their backhaul then this money has to
> come from the customers. However as things stand the 20% of customers
> grabbing 80% of the network will also grab 80% of this increased capacity,
> so they are being even more heavily cross-subsidised. Clearly cross-
> subsidy
> is always going to happen to an extent so long as you have flat fees for
> access (even if you put in tiered fees, there is still cross-subsidy). But
> this should not be excessive else customers suffer.
> 
> Toby
> 
> >
> > --
> > Mikael Abrahamsson    email: swmike@swm.pp.se
> > _______________________________________________
> > conex mailing list
> > conex@ietf.org
> > https://www.ietf.org/mailman/listinfo/conex
> 
> _______________________________________________
> conex mailing list
> conex@ietf.org
> https://www.ietf.org/mailman/listinfo/conex