From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp88.iad3a.emailsrvr.com (smtp88.iad3a.emailsrvr.com [173.203.187.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8DC4F3BA8E for ; Fri, 15 Mar 2019 19:43:59 -0400 (EDT) Received: from smtp20.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 516BD248B3; Fri, 15 Mar 2019 19:43:59 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp20.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 48D7E248C8; Fri, 15 Mar 2019 19:43:59 -0400 (EDT) Received: from app51.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 129DF248B3; Fri, 15 Mar 2019 19:43:59 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app51.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 15 Mar 2019 19:43:59 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app51.wa-webapps.iad3a (Postfix) with ESMTP id EF287A0043; Fri, 15 Mar 2019 19:43:58 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Fri, 15 Mar 2019 19:43:58 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Fri, 15 Mar 2019 19:43:58 -0400 (EDT) From: "David P. Reed" To: "Jonathan Morton" Cc: "Mikael Abrahamsson" , ecn-sane@lists.bufferbloat.net, "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20190315194358000000_32769" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <6A1F5DC5-F4D8-4C40-B4F6-1F03368F8219@gmail.com> References: <1E80578D-A589-4CA0-9015-B03B63042355@gmx.de> <27FA673A-2C4C-4652-943F-33FAA1CF1E83@gmx.de> <1552669283.555112988@apps.rackspace.com> <7412ADED-D1F3-4C15-9703-0977E087013B@gmail.com> <1552679055.131328669@apps.rackspace.com> <6A1F5DC5-F4D8-4C40-B4F6-1F03368F8219@gmail.com> Message-ID: <1552693438.976714769@apps.rackspace.com> X-Mailer: webmail/16.2.2-RC Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 23:43:59 -0000 ------=_20190315194358000000_32769 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AMy point is that the argument for doing such balancing is that somehow I= SPs at the entry points (representing somehow the goals of source and desti= nation of each flow) will classify their flows correctly based on some crit= erion, and not select the option that allows them to "beat" all the others,= which then causes them be "game theoreitically" incented to screw up the l= abeling.=0A =0AThe business argument that the users at both ends will choos= e the rignt labels is that they are responsive to price signals in a very s= ensitive way that will get them to mark things correctly. (that includes, b= y the way, the Internet Access Providers, if they take over the labeling jo= b and force their choice on their users, because they become the "endpoint"= )=0A =0ASo if pricing mechanisms don't work to incent labeling correctly, i= t does not matter that there exists an optimum that can be achieved by an O= racle who fully decides the settings on all packets of all protocols ever t= o be invented.=0A =0AAnd that's why I brought up the issue of pricing and e= conomics, which sadly really affect any kind of queue management.=0A =0ATha= t's why pricing becomes a practical issue, and issues of "utility" to the u= sers become important.=0A =0ANow the other thing that is crucial is that th= e optimal state almost all of the time of every link in the network is that= a utilization far from max capacity. The reason for this is the fact that = the Internet (like almost all networks) is bursty and fractal. The law of l= arge numbers doesn't smooth traffic volume over any timescale (that's the s= ense of fractalness here). There is no statistical smoothing of load - ther= e are rare high peaks on some links but most links are underutilized, *if y= ou want all the protocols currently used in the Internet to make users happ= y with minimal time-to-task-completion* (response time at the scale that ma= tters for the particular user's needs at that moment).=0A =0ASo if most lin= ks are uncongested most of the time (and they should be if the folks mainta= ining the subnets are all doing their job by growing links that are congest= ed to handle more traffic), then congestion management is only a peak load = problem, and only affects things a small percentage of the time.=0A =0AThis= is very, very different from the typical "benchmark" case, which focuses o= nly on dealing with peak loads, which are transient in the real world. Most= "benchmarks" make the strange and unrealistic assumption that overload is = steady state, and that users themselves don't give up and stop using an ove= rloaded system.=0A =0A =0A-----Original Message-----=0AFrom: "Jonathan Mort= on" =0ASent: Friday, March 15, 2019 4:13pm=0ATo: "Da= vid P. Reed" =0ACc: "Mikael Abrahamsson" , ecn-sane@lists.bufferbloat.net, "bloat" =0ASubject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation= and experimentation of TCP Prague/L4S hackaton at IETF104=0A=0A=0A=0A> On = 15 Mar, 2019, at 9:44 pm, David P. Reed wrote:=0A> = =0A> pricing (even dynamic pricing) of different qualities of service is un= stable=0A=0AAn interesting result, but I should note that the four-way opti= misation system I described doesn't rely on pricing, only a sufficiently co= rrect implementation of those optimisations at enough bottlenecks to make i= t worthwhile for applications to mark their traffic appropriately. The tech= nology exists to do so, but is not standardised in a way that makes it usab= le.=0A=0A - Jonathan Morton=0A=0A ------=_20190315194358000000_32769 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

My point is that the a= rgument for doing such balancing is that somehow ISPs at the entry points (= representing somehow the goals of source and destination of each flow) will= classify their flows correctly based on some criterion, and not select the= option that allows them to "beat" all the others, which then causes them b= e "game theoreitically" incented to screw up the labeling.

=0A

 

=0A

The business argument that t= he users at both ends will choose the rignt labels is that they are respons= ive to price signals in a very sensitive way that will get them to mark thi= ngs correctly. (that includes, by the way, the Internet Access Providers, i= f they take over the labeling job and force their choice on their users, be= cause they become the "endpoint")

=0A

 

=0A<= p style=3D"margin:0;padding:0;font-family: arial; font-size: 12pt; overflow= -wrap: break-word;">So if pricing mechanisms don't work to incent labeling = correctly, it does not matter that there exists an optimum that can be achi= eved by an Oracle who fully decides the settings on all packets of all prot= ocols ever to be invented.

=0A

 

=0A

And that's why I brought up the issue of pricing and economics= , which sadly really affect any kind of queue management.

=0A

 

=0A

That's why pricing becomes a pr= actical issue, and issues of "utility" to the users become important.

= =0A

 

=0A

Now the other thi= ng that is crucial is that the optimal state almost all of the time of ever= y link in the network is that a utilization far from max capacity. The reas= on for this is the fact that the Internet (like almost all networks) is bur= sty and fractal. The law of large numbers doesn't smooth traffic volume ove= r any timescale (that's the sense of fractalness here). There is no statist= ical smoothing of load - there are rare high peaks on some links but most l= inks are underutilized, *if you want all the protocols currently used in th= e Internet to make users happy with minimal time-to-task-completion* (respo= nse time at the scale that matters for the particular user's needs at that = moment).

=0A

 

=0A

So if= most links are uncongested most of the time (and they should be if the fol= ks maintaining the subnets are all doing their job by growing links that ar= e congested to handle more traffic), then congestion management is only a p= eak load problem, and only affects things a small percentage of the time.=0A

 

=0A

This is very, v= ery different from the typical "benchmark" case, which focuses only on deal= ing with peak loads, which are transient in the real world. Most "benchmark= s" make the strange and unrealistic assumption that overload is steady stat= e, and that users themselves don't give up and stop using an overloaded sys= tem.

=0A

 

=0A

 =0A

-----Original Message-----
From: "Jonathan Mo= rton" <chromatix99@gmail.com>
Sent: Friday, March 15, 2019 4:13p= m
To: "David P. Reed" <dpreed@deepplum.com>
Cc: "Mikael Abr= ahamsson" <swmike@swm.pp.se>, ecn-sane@lists.bufferbloat.net, "bloat"= <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [Ecn-sane] [= iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4= S hackaton at IETF104

=0A
= =0A

> On 15 Mar, 2019, at 9:44 pm, David P. Reed <= ;dpreed@deepplum.com> wrote:
>
> pricing (even dynamic = pricing) of different qualities of service is unstable

An intere= sting result, but I should note that the four-way optimisation system I des= cribed doesn't rely on pricing, only a sufficiently correct implementation = of those optimisations at enough bottlenecks to make it worthwhile for appl= ications to mark their traffic appropriately. The technology exists to do s= o, but is not standardised in a way that makes it usable.

- Jon= athan Morton

=0A
 ------=_20190315194358000000_32769--