Re: [Bloat] this explains speedtest stuff

[Dave Taht <dave.taht@gmail.com>]

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 <chromatix99@gmail.com> wrote:
>
> > On 25 Apr, 2020, at 5:14 pm, Kenneth Porter <shiva@sewingwitch.com> 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
> Bloat@lists.bufferbloat.net
> 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