Trying to improve the dslreports misguided "Quality" metric by enabling ecn is essentially "engineering to the test" rather than providing much actual benefit. It would be rather useful at the moment to do that test given the 50/50 mbit symmetric nature of this one, and also collect QoE metrics over time. I'd rather like kenneth to try it!
The use case here includes vpn, smb filesharing, and rdp. Enabling ecn universally for all the endpoints involved is adding in a few lines of configuration for all those endpoints, and rdp itself is a hybrid tcp/udp protocol. https://en.wikipedia.org/wiki/Remote_Desktop_Protocol about the congestion control characteristics of the udp portion in all the competing implementations is kind of unknown but seem likely to be poor. It would be a useful test for an intrepid windows administrator to actually enable ecn fully and see what breaks in their vpn, smb, and rdp implementations, and across their remote workforce, and observe any difference in QoE. I have long tried to get one drunk enough to deploy ecn across their windows infrastructure without any success. However it is perhaps useful to point to a few detailed statistics the dslreports test also gets incorrect. Going to the "good" result: http://www.dslreports.com/speedtest/62803997 The summary stats on the "Server view" of this page appear to be incorrect. In particular they claim severe flow unfairness by RTT, where the logs further down on the page, do not. retransmits are pretty high, nearly 5%, but that too could be an error. certainly repeating the test with ecn enabled should eliminate retransmits caused by loss on this part of the path! IMHO: Packet loss, in modest amounts, really has no impact on "quality" for most TCP flows. If you lose a few packets in a flow that takes 2 seconds to complete, only tail loss is going to hurt you, (if it happens), otherwise, the maximum rtt observed here was a physical 64ms +- 12ms, which means that (so long as it isn't tail loss) that the total time to complete a 2 second tcp transaction would be inflated 130ms or so, and most of the time... 0. When you look at the overall benefit of applying advanced AQM techniques to this link verses the original test ( http://www.dslreports.com/speedtest/62767361) , there is a savings of 480ms of peak latency in the uplink direction and 150ms in the down. On a path measured in the 4ms range, that's a really enormous savings, and I'd hope that his users could see an observable difference - or rather, merely not notice anyone else was using the link, all the time. The characteristics of smb traffic are very different from web traffic. file downloads and uploads are common, file locking and directory operations are very short, and there's all kinds of short administrative traffic for kerberos tickets and the like. since (I think?) the proposed vpn traffic is client -> server (?) not, clients -> router -> server, each individual using this link over the vpn will tend to get their own queue, and a big upload or download through their openvpn will tend to "do them in", because openvpn has lousy queue management internally... and (when last I looked), windows itself had not a lot of backpressure when dealing with that device. as for rdp traffic, well... I do kind of wish rdp worked over webrtc instead and rather than using vpns we could actually expose good applications to ipv6 and the internet at large, but I do like to sleep at night, also. I wish (for example) I could trust smb3 to be deployed everywhere and we could go back to good ole drag and drop filesharing, with support for remote locking, and none of this port 433 only nonsense. On Sat, Apr 25, 2020 at 7:19 AM Jonathan Morton <[email protected]> wrote: > > > On 25 Apr, 2020, at 5:14 pm, Kenneth Porter <[email protected]> wrote: > > > > I see "ecn" in the qdisc commands. > > No, not the qdisc (where ECN is enabled by default), but on the client. > > Linux: > # sysctl net.ipv4.tcp_ecn=1 > > Windows: > > netsh interface tcp set global ecncapability=enabled > > OSX: > $ sudo sysctl -w net.inet.tcp.ecn_initiate_out=1 > $ sudo sysctl -w net.inet.tcp.ecn_negotiate_in=1 > > In Linux and OSX, to make the setting persist across reboots, edit > /etc/sysctl.conf. > > - Jonathan Morton > _______________________________________________ > Bloat mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/bloat -- Make Music, Not War Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729 _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
