From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 023B13B29E for ; Sat, 25 Apr 2020 11:43:21 -0400 (EDT) Received: by mail-io1-xd34.google.com with SMTP id i3so13884513ioo.13 for ; Sat, 25 Apr 2020 08:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Yk6u2HmVh2TIS1N5lGkK5LTPp3Zz3hsYH/1Jstvffl8=; b=dq4WW/kJrJ8DwGljj1OjtgfiN9ZYSnnFPhrxCsjSIPFu3MbEYsWXm0k9TXirDVimRk VRgaYoHuBo87k3MheJkh/4T4bSZjyBtDRtBIiWochn8Um8TI+J/eGgc8vyVyqkOnObiO rEJ1GfnE6TRNbeSHX/a1bwnFWDssBOiE0P8wMKFaKOPe3Kf/Btmz44S4r+h1nteIb/mL ruW2PAaGsgrU3f17MmQMWJlaaeRl9jOGAomw74LDAbYYVRa/bTFqjp5tRt7vVx7i297/ qJcHKHDGIxiux04PIHDdPbwgmPbxPlXsxHLqLcgwpAHN8kj1wBLU459YkAHPFV+jBQak IFfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Yk6u2HmVh2TIS1N5lGkK5LTPp3Zz3hsYH/1Jstvffl8=; b=btDm7rmmLUEQR/R3iNVngHEpemMwDRRC4sS5RpM1EJwbH/SBCfe9n5BoN/9XYH9RWY RUb9np/v6aSD4+5UoOwnRCqFUEyAVwMO0iKAkYGIV00lWs51hXtxvMk6NB1KE3Z7UehO BZ3dGF0vh2J+cMdzJtjAarMgTgf5HZvuZNqelKc5CYABo4ZRVn+6sIO9SFVFBmgFt32q mltZrPzauh7qHeKJjDclv2j5C8eJf1rzJaX9sW5P0vLAH5q5cQhdzwXXAp4i8X9k0N31 W5HBWr4mrG0RpPP4eKrTjmS4S8wsFh7bG4xIkRy78dv+4kOgELwv6MoJYlNxW88C4nAi DdJg== X-Gm-Message-State: AGi0PuY/0khlbHDWZPco+vOro5uAjzSrfzQWw/QIErEbVTX3uvtfJZYO UL0/KyfnDXefh+ULhgz/ryv1m/fdgwAEKuqKY4XPO3l7 X-Google-Smtp-Source: APiQypIy2Z7ifHxY6zzfZ4hvc/HNH6cKsGlTRFckT95kkKOIjQFI3Ksm1ciwu/ek9ygkFKhxUmVbtgW/nXyfRoOuqO0= X-Received: by 2002:a05:6638:247:: with SMTP id w7mr13283013jaq.128.1587829401339; Sat, 25 Apr 2020 08:43:21 -0700 (PDT) MIME-Version: 1.0 References: <431A84397F3D9C1EB097BCCE@[172.27.17.193]> <6F1F3C646A7DFD2CC8C9E79E@172.27.17.193> <0B51625096F92AF18CD397D9@[172.27.17.193]> <8f4566dd-def0-cd97-45db-577784f90efd@sewingwitch.com> <9FDDBB5C-68CF-45B1-85D8-3A7BD6CB9F31@gmail.com> <3D2F4A70BAB1774D1EFDC641@[172.27.17.193]> <025E1E0E1D49D3C95FFD4035@[172.27.17.193]> <03E39523-C125-4A03-A514-30CA4E361225@gmail.com> In-Reply-To: From: Dave Taht Date: Sat, 25 Apr 2020 08:43:09 -0700 Message-ID: To: Jonathan Morton Cc: Kenneth Porter , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] this explains speedtest stuff X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 15:43:22 -0000 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 wrote: > > Trying to improve the dslreports misguided "Quality" metric by enabling e= cn 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 w= rote: > > > > > On 25 Apr, 2020, at 5:14 pm, Kenneth Porter w= rote: > > > > > > 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=3D1 > > > > Windows: > > > netsh interface tcp set global ecncapability=3Denabled > > > > OSX: > > $ sudo sysctl -w net.inet.tcp.ecn_initiate_out=3D1 > > $ sudo sysctl -w net.inet.tcp.ecn_negotiate_in=3D1 > > > > 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=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-435-0729 --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729