<font face="arial" size="3"><p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">Just to throw in one more thing not well understood by engineers.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">Economists I have discussed this with (real ones, not fringe right-wing true believers that the market "just works"), have observed that pricing (even dynamic pricing) of different qualities of service is unstable and extremely unlikely to reflect the correct price for the particular utility of the achieved service quality.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">The point of that observation is that even a simple 2 classes of service system (so-called Paris Metro Pricing) 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.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">I can explain more, but the end user doesn't benefit from multiple choices of class of service at the packet level.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">-----Original Message-----<br />From: "Jonathan Morton" <chromatix99@gmail.com><br />Sent: Friday, March 15, 2019 3:32pm<br />To: "Mikael Abrahamsson" <swmike@swm.pp.se><br />Cc: "David P. Reed" <dpreed@deepplum.com>, ecn-sane@lists.bufferbloat.net, "bloat" <bloat@lists.bufferbloat.net><br />Subject: Re: [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104<br /><br /></p>
<div id="SafeStyles1552678581">
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">> On 15 Mar, 2019, at 8:36 pm, Mikael Abrahamsson <swmike@swm.pp.se> wrote:<br />> <br />> Having a "lower-than-best-effort" diffserve codepoint might work, because it means worse treatment, not preferential treatment.<br />> <br />> The problem with having DSCP CPs that indicate preferential treatment is typically a ddos magnet.<br /><br />This is true, and also why I feel that just 2 bits should be sufficient for Diffserv (rather than 6). They are sufficient to express four different optimisation targets:<br /><br />0: Maximum Throughput (aka Best Effort)<br />1: Minimum Cost (aka Least Effort)<br />2: Minimum Latency (aka Maximum Responsiveness)<br />3: Minimum Loss (aka Maximum Reliability)<br /><br />It is legitimate for traffic to request any of these four optimisations, with the explicit tradeoff of *not* necessarily getting optimisation in the other three dimensions.<br /><br />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 much ripe for abuse if not strictly admission-controlled). TOS was rightly considered a mess, but was replaced with Diffserv which was far too loose a spec to be useful in practice.<br /><br />But that's a separate topic from ECN per se.<br /><br /> - Jonathan Morton<br /><br /></p>
</div></font>