From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp124.iad3a.emailsrvr.com (smtp124.iad3a.emailsrvr.com [173.203.187.124]) (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 9B43B3CB36 for ; Fri, 15 Mar 2019 15:44:15 -0400 (EDT) Received: from smtp32.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5F20254F5; Fri, 15 Mar 2019 15:44:15 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp32.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5916154FB; Fri, 15 Mar 2019 15:44:15 -0400 (EDT) Received: from app60.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 32C8454F5; Fri, 15 Mar 2019 15:44:15 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app60.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 15:44:15 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app60.wa-webapps.iad3a (Postfix) with ESMTP id 20B3CC0044; Fri, 15 Mar 2019 15:44:15 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Fri, 15 Mar 2019 15:44:15 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Fri, 15 Mar 2019 15:44:15 -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="----=_20190315154415000000_46222" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <7412ADED-D1F3-4C15-9703-0977E087013B@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> Message-ID: <1552679055.131328669@apps.rackspace.com> X-Mailer: webmail/16.2.2-RC 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: Fri, 15 Mar 2019 19:44:15 -0000 ------=_20190315154415000000_46222 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AJust to throw in one more thing not well understood by engineers.=0A =0A= Economists I have discussed this with (real ones, not fringe right-wing tru= e believers that the market "just works"), have observed that pricing (even= dynamic pricing) of different qualities of service is unstable and extreme= ly unlikely to reflect the correct price for the particular utility of the = achieved service quality.=0A =0AThe point of that observation is that even = a simple 2 classes of service system (so-called Paris Metro Pricing) is uns= table, such that users of such a system will not be encouraged to set the p= riorities/service types to make system optimal or stable.=0A =0AI can expla= in more, but the end user doesn't benefit from multiple choices of class of= service at the packet level.=0A-----Original Message-----=0AFrom: "Jonatha= n Morton" =0ASent: Friday, March 15, 2019 3:32pm=0AT= o: "Mikael Abrahamsson" =0ACc: "David P. Reed" , ecn-sane@lists.bufferbloat.net, "bloat" =0ASubject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implemen= tation and experimentation of TCP Prague/L4S hackaton at IETF104=0A=0A=0A= =0A> On 15 Mar, 2019, at 8:36 pm, Mikael Abrahamsson wro= te:=0A> =0A> Having a "lower-than-best-effort" diffserve codepoint might wo= rk, because it means worse treatment, not preferential treatment.=0A> =0A> = The problem with having DSCP CPs that indicate preferential treatment is ty= pically a ddos magnet.=0A=0AThis is true, and also why I feel that just 2 b= its should be sufficient for Diffserv (rather than 6). They are sufficient = to express four different optimisation targets:=0A=0A0: Maximum Throughput = (aka Best Effort)=0A1: Minimum Cost (aka Least Effort)=0A2: Minimum Latency= (aka Maximum Responsiveness)=0A3: Minimum Loss (aka Maximum Reliability)= =0A=0AIt is legitimate for traffic to request any of these four optimisatio= ns, with the explicit tradeoff of *not* necessarily getting optimisation in= the other three dimensions.=0A=0AThe old TOS spec erred in specifying 4 no= n-exclusive bits to express this, in addition to 3 bits for a telegram-offi= ce style "priority level" (which was very much ripe for abuse if not strict= ly admission-controlled). TOS was rightly considered a mess, but was replac= ed with Diffserv which was far too loose a spec to be useful in practice.= =0A=0ABut that's a separate topic from ECN per se.=0A=0A - Jonathan Morton= =0A=0A ------=_20190315154415000000_46222 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Just to throw in one m= ore thing not well understood by engineers.

=0A

&nbs= p;

=0A

Economists I have discussed this with (real o= nes, not fringe right-wing true believers that the market "just works"), ha= ve observed that pricing (even dynamic pricing) of different qualities of s= ervice is unstable and extremely unlikely to reflect the correct price for = the particular utility of the achieved service quality.

=0A

 

=0A

The point of that observation is = that even a simple 2 classes of service system (so-called Paris Metro Prici= ng) is unstable, such that users of such a system will not be encouraged to= set the priorities/service types to make system optimal or stable.

=0A<= p style=3D"margin:0;padding:0;font-family: arial; font-size: 12pt; overflow= -wrap: break-word;"> 

=0A

I can explain more, b= ut the end user doesn't benefit from multiple choices of class of service a= t the packet level.

=0A

-----Original Message-----From: "Jonathan Morton" <chromatix99@gmail.com>
Sent: Friday= , March 15, 2019 3:32pm
To: "Mikael Abrahamsson" <swmike@swm.pp.se&= gt;
Cc: "David P. Reed" <dpreed@deepplum.com>, ecn-sane@lists.bu= fferbloat.net, "bloat" <bloat@lists.bufferbloat.net>
Subject: Re= : [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experiment= ation of TCP Prague/L4S hackaton at IETF104

=0A
=0A

> On 15 Mar, 2019, at 8:36 p= m, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>
> = Having a "lower-than-best-effort" diffserve codepoint might work, because i= t means worse treatment, not preferential treatment.
>
> T= he problem with having DSCP CPs that indicate preferential treatment is typ= ically a ddos magnet.

This is true, and also why I feel that jus= t 2 bits should be sufficient for Diffserv (rather than 6). They are suffic= ient to express four different optimisation targets:

0: Maximum = Throughput (aka Best Effort)
1: Minimum Cost (aka Least Effort)
2= : Minimum Latency (aka Maximum Responsiveness)
3: Minimum Loss (aka Ma= ximum Reliability)

It is legitimate for traffic to request any o= f these four optimisations, with the explicit tradeoff of *not* necessarily= getting optimisation in the other three dimensions.

The old TOS= spec erred in specifying 4 non-exclusive bits to express this, in addition= to 3 bits for a telegram-office style "priority level" (which was very muc= h ripe for abuse if not strictly admission-controlled). TOS was rightly con= sidered a mess, but was replaced with Diffserv which was far too loose a sp= ec to be useful in practice.

But that's a separate topic from EC= N per se.

- Jonathan Morton

=0A
 ------=_20190315154415000000_46222--