Re: [Bloat] this explains speedtest stuff

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

and the last flaw of this test series is that ken took the dslreports
"fiber" setting for the dslreports test as "The right thing". the
"fiber" test is structured to stress test an asymmetric 1gbit/100mbit
connection, not a shaped fiber connection running at 50mbit symmetric.
The number of uploads is 4, downloads, 32.... it's totally ok to pick
a given fiber/cable/whatever test, but it does help to apply the same
characteristics to more of the tests you do, if you are trying to
compare technologies.

that said, I'm rather happy to see cake survive the onslaught of 32
simultaneous download flows at a range of rtts from 4ms to 64ms, with
flow fairness.

On Sat, Apr 25, 2020 at 8:32 AM Dave Taht <dave.taht@gmail.com> wrote:
>
> 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



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729