From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 7CADD3B29E for ; Sat, 25 Apr 2020 11:32:36 -0400 (EDT) Received: by mail-io1-xd2e.google.com with SMTP id p10so13895269ioh.7 for ; Sat, 25 Apr 2020 08:32:36 -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=9fl5aK3Onr8/sTFpcVDr5N1cqPgXPes3nViieD9XgvY=; b=JT2R2OzQC4XEVPPjHB1PV8WzCuP2tUKo8rTRfR4CvlN8Mxe3hRnX3CXCWWFMbz5UCM Qe+Ax2Sm8C52jAU5HZYHXwblqgCVo952b4sI7JpjvouQvKON0eXZBHDF/rG1RTgovP/7 MSzW7KS2ehmHHQKgiPk/vH1UvrgheNYL6wfjHoaAGMrWrNQnoW7mSjR45unckMMJbK0n S52vRiTYvPUU05PRBGW051CsvrjaSI1VSAVcd0lgwpdOUwk4i7Ls/feFWthXrTGwky/S kKB5rGH6wSP9rnCnvHfg9uKhUgJesRRGCmiZH4fSzV0HNu1nj0fBZU994++kGTaGYDcs gwmw== 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=9fl5aK3Onr8/sTFpcVDr5N1cqPgXPes3nViieD9XgvY=; b=QwcrUSIPTN8MbizrbwDUwVu2z65Np92pTuctDDxaG3kqXWoKI8fPiPTvo1HZjQ8Lkt 6BVACopYNhc4nE2IxIWmHvQnKIZrce9P7L7xirxfWgXuELfvPsGaLghRkLqAkmJIang6 BmWLDKolZnLKBcvZKcL+ts7v7GAA6YEc8qFt7EiZfevEFmG06DK0VOuMQTjrR5rEOQfx xg/FmAKQ9eNM1h63ara/DAua1bc6L6rXrxsifmn8eiSou7b1b1Bw0a/eRSKexxveMpce n3RzAidqlP6pdy0L+ON/qV5n1uxOI8adZ8mF/fA6EhGZ1KiN0T0QvlK54UVVV3uVJSUp fz7Q== X-Gm-Message-State: AGi0PubZtK+R8Qvj6y8DjUPuLd9qFdGVm8KmLPXdak/OrZR/Y9TelBFs 3JHIYLLoBSzh1AC14fzBC8/QVoimn8urGrrrDrU= X-Google-Smtp-Source: APiQypINy6Gszvm3cqdUAhtbjIKIeVp+Exgkb9YSzwoS5hHGF2QWABP+lWMnN/CP7i0hZq0qZAOn1ancBHOTZFaNLd0= X-Received: by 2002:a02:cd03:: with SMTP id g3mr12695650jaq.61.1587828755808; Sat, 25 Apr 2020 08:32:35 -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: <03E39523-C125-4A03-A514-30CA4E361225@gmail.com> From: Dave Taht Date: Sat, 25 Apr 2020 08:32:23 -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:32:36 -0000 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 wro= te: > > > On 25 Apr, 2020, at 5:14 pm, Kenneth Porter wro= te: > > > > 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/s= ysctl.conf. > > - Jonathan Morton > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729