Re: [tcpm] [EXTERNAL] Re: A possible simplification for AccECN servers

[Praveen Balasubramanian <[e-mail]>]

To clarify Windows Server will do that but not any of the client editions. And the default for Server has also been flipped to CUBIC in the most recent release. 

-----Original Message-----
From: tcpm <[e-mail]> On Behalf Of Richard Scheffenegger
Sent: Thursday, December 12, 2019 10:53 AM
To: Jonathan Morton <[e-mail]>
Cc: Matt Mathis <mattmathis=[e-mail]>; tcpm IETF list <[e-mail]>; Mirja Kuehlewind <[e-mail]>
Subject: [EXTERNAL] Re: [tcpm] A possible simplification for AccECN servers

Just remember that windows will nowadays go with dctcp if you turn on ecn, and the server is less than 10ms rtt away (which is possible in cities where a cdn colocates with your isp...)

Just sayin’ :)

Gesendet mit der GMX Mail App

Am 12.12.19 um 19:32 schrieb Jonathan Morton

> > On 12 Dec, 2019, at 5:07 pm, Matt Mathis <mattmathis=[e-mail]> wrote:
> > 
> > Is there any reason to want to have 3168 and AccECN coexistence beyond a transition?  Put another way, if we imagine fully supporting both 3168 and AccECN, it there any reason to choose 3168 other than deployment inertia?
> 
> Because there are still potential valid experiments which build upon RFC-3168 signalling, including SCE, which may yet prove popular.  I think it would be exceedingly short-sighted to prevent such experiments from succeeding, and not just because I happen to be involved in one.
> 
> And because there's an *awful lot* of RFC-3168 compliant endpoints out there.  Every current Apple product requests RFC-3168 ECN by default.  Some major Linux distros do as well, and for all others it's a mere sysctl away.  Even Windows users can turn it on just as easily, though it is not on by default.
> 
> The ECN-aware middleboxes intended for use on last-mile links and as wifi APs also universally signal in the RFC-3168 manner and expect an RFC-3168 (or RFC-8511) compliant response.  I've found CPE advertising support for exactly this on the shelf.  The recent "make wifi fast" modifications to the Linux wifi stack include a built-in fq_codel AQM for the very common ath9k, ath10k and mt76 hardware.
> 
> That deployment remains low in the carrier-grade market is increasingly anomalous (and mostly due to a chicken-and-egg situation whereby carriers can't turn it on because HW doesn't support it, and HW vendors don't implement it because their customers don't make a stink about it).  Nevertheless, at least two major European ISPs are known to have deployed fq_codel in both directions, in the name of improving customers' QoS.
> 
> This is what I mean by RFC-3168 deployment "taking off" in the past few years.  There's a lot more of it now than there was five years ago, due in large part to the superlative performance of Codel AQM - which is *specifically* designed around RFC-3168 response characteristics.  We've already discussed this somewhat in TSVWG.
> 
>  - Jonathan Morton

_______________________________________________
tcpm mailing list
[e-mail]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40microsoft.com%7C2137c81afa6143286c9308d77f349992%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117736214183837&amp;sdata=d8q8I53jQUzu01fVI%2FbGf97tVXHcSYSrUrZvMRPo0gw%3D&amp;reserved=0