From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B67EB3BA8E; Sat, 16 Mar 2019 03:38:57 -0400 (EDT) Received: from [10.200.213.58] ([80.187.113.160]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MSv6D-1hUfwO45xd-00Ro2B; Sat, 16 Mar 2019 08:38:54 +0100 Date: Sat, 16 Mar 2019 08:38:48 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <1552693438.976714769@apps.rackspace.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> <1552693438.976714769@apps.rackspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: bloat@lists.bufferbloat.net, "David P. Reed" , Jonathan Morton CC: bloat ,ecn-sane@lists.bufferbloat.net From: Sebastian Moeller Message-ID: <550B4916-FEC9-460E-BAF9-ACD125F3F6E8@gmx.de> X-Provags-ID: V03:K1:XSHeur4rNQCrpa+b1jo8cdsgEhcVCE39MFmygcCKEL4y8Czpjdt AZtAjmbP2rzUky4udJlqIQnE7hS9doMoLnLrbGufTyysXPdRdCd4K/C/M4UZKz7RHDU8ajv 06iO0+zxhWBk7yYgSZ3b5EZ3pHU2XzZl6jLvgFzktY+CGrTPZzyrLBQk2U7uBovI+t+yDYP w4LuNnzyaeRWY6g09LQoA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Ewd6wfVFTgc=:ZJpW2BnaqA3BlMGKg6MaQV Zg42S7y1N37YJEeedn2XLXXugnBRLxESghnTO/Cn9VwieNM1knZsp/y9nGUs2S+XM9H1QVw0S rrl+PwvIcn3q2NQ5w/W5JIsGq3HyJAa+BOpsh/vJjDu/knu1pYWLI03haqcLnJ6eOUzAyA+hO BARFCAMCst0apVQRllHf3UvxdZ7tZwx3T0/HhOgjidrbiRTwRjMf8i5OHemGZSbzH/xN/3NZm Yvgu+aIhmD83Dgr2c5bPGDiVYV+dll/BCx0+Ck8TKLhx5IueprfwCKz5ysDbnD+azyb0F/vkE zkPUUFzIp2SiHAuZXI7NthY1Kj11Z5DHKxcQSu1yeSYbyTcqe55c0vqi/NOaCTZcVBtVKIrFb PpuYAtQX++HL6u1syQ3mpTL0kwRKnIjdt+G5vRljGV23+gpNvFy+Q3pSOJaxwIwrCleGs+Gc5 zzwIzer0Rx+eM4Lj0+I9UqRlmcsoQFFsvBAMTwP3Uyfet/qh2EvcOpWe+04DfKOMHVDRCEyBW 9N/SCQzdQyKFQNoTzGrRQtnE0+0/3oD3XZu0JdnTNzqqBKZsb4de92QM7EcIBOa5AvP3qIygs nrgczzfqoMoGmst3qUXa+rTzMR0qbhaF6coQMrqrm71iCh8mnrTPdatKlosXH01XH46hIfDzA WR8QukQwxBPeTUVdoln2Hh2VUGjfvI4BObDS3CnIl/bBwp9IXrN/WcBugthN68rURJEAuHvmX +b8oG4OhVcRcETxgHNvZodKhDk/CRqQ2eGvA+VvkqcT0Unh56ClNy4+dr5ocnNkc+/RExBtbv OvlkEpmY6joVwPMq5Q4sT6+KMlsgdncwGI/KlgN1jO2FV4FXgG+xhratklV4x+bHETQAVHedj 9PtrExOFF+ef0p85yCgf3FR3thda5sPSRHcIhpymym/0K4mlCwsZBkxUr995Uw4TmM5BTOENI kY8EcVYON+w== Subject: Re: [Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104 X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2019 07:38:58 -0000 Hi Dave, On March 16, 2019 12:43:58 AM GMT+01:00, "David P=2E Reed" wrote: > >My point is that the argument 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 be "game theoreitically" >incented to screw up the labeling=2E One more argument for splitting the 6 dscp bits, one half for the ISP one = half for end to end signalling=2E=2E=2E I do neither expect ISPs to honor the intent bits (with the possible excep= tion of the LE patter, there e2e and ISP goals seem aligned) and I also do = not see any approach gain traction that completely takes the dscp bits away= from the intermediate transports, whether one likes it or not, these effec= tively are under transport control and are actually used, so hoping the cur= rent owner giving all of them back seems overly optimistic=2E Hence the 50/= 50 split=2E >=20 >The business argument that the users at both ends will choose the rignt >labels is that they are responsive to price signals in a very sensitive >way that will get them to mark things correctly=2E Right or wrong, or how to interpret the different pattern is a question th= at only becomes relevant once the patterns are signalled robustly end to en= d=2E=2E=2E (that includes, by the >way, the Internet Access Providers, if they take over the labeling job >and force their choice on their users, because they become the >"endpoint") Not with the split proposal, and yes end users depend on their ISP doing r= easonable traffic management, but that seems orthogonal to dscp bit pattern= s to me=2E >=20 >So if pricing mechanisms don't work to incent labeling correctly, it >does not matter that there exists an optimum that can be achieved by an >Oracle who fully decides the settings on all packets of all protocols >ever to be invented=2E >=20 >And that's why I brought up the issue of pricing and economics, which >sadly really affect any kind of queue management=2E Sure in the context of hoping the ISPs and the wider internet respecting e= ndpoint set dscps that seems all applicable=2E >=20 >That's why pricing becomes a practical issue, and issues of "utility" >to the users become important=2E >=20 >Now the other thing that is crucial is that the optimal state almost >all of the time of every link in the network is that a utilization far >from max capacity=2E The reason for this is the fact that the Internet >(like almost all networks) is bursty and fractal=2E The law of large >numbers doesn't smooth traffic volume over any timescale (that's the >sense of fractalness here)=2E There is no statistical smoothing of load - >there are rare high peaks on some links but most links are >underutilized, *if you want all the protocols currently used in the >Internet to make users happy with minimal time-to-task-completion* >(response time at the scale that matters for the particular user's >needs at that moment)=2E >=20 >So if most links are uncongested most of the time (and they should be >if the folks maintaining the subnets are all doing their job by growing >links that are congested to handle more traffic), then congestion >management is only a peak load problem, and only affects things a small >percentage of the time=2E I concur with Jonathan, access links often run much closer to their limit = than core networks, and the whole bufferbloat project demonstrated that a c= apable AQM system with mild tiering can make a saturated link still accepta= ble to use even for low latency applications=2E=2E=2E But for ingress shaping it would be really great to have some trustworthy = way of deducing the sender's intent, and dscps seem like a natural fit=2E Best Regards Sebastian >=20 >This is very, very different from the typical "benchmark" case, which >focuses only on dealing with peak loads, which are transient in the >real world=2E 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 overloaded system=2E >=20 >=20 >-----Original Message----- >From: "Jonathan Morton" >Sent: Friday, March 15, 2019 4:13pm >To: "David P=2E Reed" >Cc: "Mikael Abrahamsson" , >ecn-sane@lists=2Ebufferbloat=2Enet, "bloat" >Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation >and experimentation of TCP Prague/L4S hackaton at IETF104 > > > >> On 15 Mar, 2019, at 9:44 pm, David P=2E Reed >wrote: >>=20 >> pricing (even dynamic pricing) of different qualities of service is >unstable > >An interesting result, but I should note that the four-way optimisation >system I described doesn't rely on pricing, only a sufficiently correct >implementation of those optimisations at enough bottlenecks to make it >worthwhile for applications to mark their traffic appropriately=2E The >technology exists to do so, but is not standardised in a way that makes >it usable=2E > > - Jonathan Morton --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E