From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 C1DDC3B260 for ; Mon, 29 Aug 2016 21:05:56 -0400 (EDT) Received: by mail-it0-x244.google.com with SMTP id n75so731602ith.0 for ; Mon, 29 Aug 2016 18:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=7eqi1eMWthWUw6mvu5WXO1Wbqrb73dOsfXIqEpdl/Q0=; b=M3u4bRW9BaAK4ZyRSerx9ZoQ3RcufYiauOqbF3B6YD8sK3ylkOcfjHX81ILLxxa7i1 wh9poR9moKawg0BqfeNZLZpWSCjYRARsxCIgsFgVTNlQoOeoNM7A74ndbib4UUXTg+XS fu2rb4WXcDpB/aL24BwvpUPga4A5cV8hZrcKPsodOvB4LqFt/Wp4zXB9e+CbG6jJY3Jc 7YWWRnEfPxVXznQ4whkMLkyeRKOJ1F6le+9VHtSuwGUEumLavAlSGH1CYDho0Hca7wqS zkpginAhHgpaWGst1Gar6tR7Q2gYM1AORJzn2usJZxggvt45esymkRRJWLRvv2NV2tBm 69/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=7eqi1eMWthWUw6mvu5WXO1Wbqrb73dOsfXIqEpdl/Q0=; b=S6ua5wbqBULIxdEIArifVFxWg4gQbLCQEuAbi76G5q0s2e8J9KO1JTFpvVlsyoK72T lNGumS2bccvEhuEZ/bIOJ+W8++mwEvQqjNyEALj4QnFppK6/nzSoMU/pOD8ngi2ps7is tyMK/VNHP3+BLevbAT+F+Gs2VJ1mQbXgqdr/LqSUhO+NSkbAspCPIihLAsZVR+tdksTp VForvViNCaNEmf0C6TfE30d2HC9ZHCeo6c+XV+tHmKM05osbN1NGKbmJ208DrHeLOBY3 5AWshTClzLI02VAAofUsczXDgHobs85lQY6+0sb2Su5k8tHbanp1EeUC+xlCGM+CLaUd 9iJQ== X-Gm-Message-State: AE9vXwP6ZDJ+hP1VUgD5nGuHARY8O1/cF4GLJsetHAW34CakNU9kwHyQNnEl5X/Hjk0pxIhJRZ5WAs5oUN2EHg== X-Received: by 10.36.20.204 with SMTP id 195mr19409765itg.83.1472519156073; Mon, 29 Aug 2016 18:05:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.13.200 with HTTP; Mon, 29 Aug 2016 18:05:55 -0700 (PDT) From: Dave Taht Date: Mon, 29 Aug 2016 18:05:55 -0700 Message-ID: To: cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cake] target 83ms at 10Mbit?? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 01:05:56 -0000 One puzzling thing about this was that cake reports a target 83ms here... old iproute2? odd report from cake?interaction with the network namespace subsystem? what? In other news, ecn support was just more or less successfully applied to wireguard, a new vpn that looks pretty cool. http://wireguard.io/ relevant conversation on the list ---------- Forwarded message ---------- From: Jason A. Donenfeld Date: Mon, Aug 29, 2016 at 4:57 PM Subject: Re: [WireGuard] fq, ecn, etc with wireguard To: Dave Taht Cc: WireGuard mailing list > well, you should see ect(3) if you pound the network interface. Things > like tcp small queues get in the way so you won't see it with a simple > single flow test against cake/codel/etc. > > something like 4 netperfs will do it. It works! 01:40:57.962131 IP (tos 0x3,CE, ttl 64, id 51647, offset 0, flags [none], proto UDP (17), length 1480) I made this happen by giving `-P 50 -N -w 500M ` to iperf3. > sudo apt-get install python-matplotlib python-qt4 netperf fping # some > git clone https://github.com/tohojo/flent.git > cd flent; sudo make install > flent-gui *.gz > I am a big fan of flent to generate tests with, and tcptrace -G on the > capture of the decrypted interface and looking at the output via > xplot.org (not xplot). Looking at the resulting capture on one end, > you will see the CE going out, on the other you will see just the CWR > and little dots showing the acks acknowledging the CE has been heard > and acted upon. Excellent, thanks for the suggestions on testing tools. I've been using ipe= rf3 nearly exclusively, and indeed it seems like netperf and others are substantially more powerful. I've also got a directory of horrible .c progr= ams generating packets for stress testing printing out text for me to pop into Mathematica... Clearly my homebrewed rig isn't going to be useful for much longer. I'll look into getting these setup. > # Anyway, I'll join you in irc to look over what you doing..... Sorry -- when you messaged me in there, I was just getting off a big 14 hou= r international flight. I've got a long layover now, and probably I'll be in = IRC again if you want to pop in there. Though, I'm quite exhausted and might collapse on some airport benches... > Then by all means follow the existing latest code. Well that was my question. Should I follow (A) or (B)? IPsec does (B); everything else does (A). Does IPsec have a security reason for doing (B)? = Is there some denial of service attack that can be mounted, or some informatio= n disclosure, or some sort of oracle attack? Or is (A) pretty much clearly better and more robust under abuse, and IPsec is just behind the times? Probably I shoul djust read the ECN RFCs to actually understand what all th= is is doing and make up my mind. > Postel is long dead, and the internet is a far more hostile place. > so did cake manage to successfully ratelimit the output to 10Mbit's in > this configuration? It did. With I rate limited the actual link to 10mbps, and iperf3 got aroun= d 9mbps over TCP, which seems about right considering TCP and considering the packet encapsulation overhead. > > cake's stats also show marks and drops. (tc -s qdisc show dev lo) Seems to work: qdisc cake 8008: root refcnt 2 bandwidth 10Mbit diffserv4 flows rtt 100.0ms raw Sent 82329355 bytes 95473 pkt (dropped 5295, overlimits 195966 requeue= s 0) backlog 137124b 150p requeues 0 memory used: 502566b of 500000b capacity estimate: 10Mbit Tin 0 Tin 1 Tin 2 Tin 3 thresh 10Mbit 9375Kbit 7500Kbit 2500Kbit target 78.7ms 83.9ms 104.9ms 314.6ms interval 173.7ms 178.9ms 209.8ms 629.3ms Pk-delay 0us 93.9ms 0us 0us Av-delay 0us 91.2ms 0us 0us Sp-delay 0us 83.8ms 0us 0us pkts 0 100916 2 0 bytes 0 84254676 318 0 way-inds 0 0 0 0 way-miss 0 1 1 0 way-cols 0 0 0 0 drops 0 5295 0 0 marks 0 4660 0 0 Sp-flows 0 0 0 0 Bk-flows 0 1 0 0 last-len 65536 0 0 0 max-len 0 1494 187 0 > acks do not get ECN marks. I'll need to think carefully about the infoleak aspects of allowing ECN. It seems nearly as bad as the DSCP infoleak. Is this information that's okay t= o be sent in the clear? I'm not quite sure yet. > (I note that mosh is also ecn enabled, last I looked) Cool. I recall when they added the DSCP priority, but I don't recall ECN. I= 'll try that out. I'm a big Mosh user -- and the roaming feature of WireGuard w= as inspired by it. > I will. I got very busy today getting a "final" version of the > fq_codel code for ath9k wifi tested. It's lovely. :) If you are into > openwrt, we've got builds available at: > > https://lists.bufferbloat.net/pipermail/make-wifi-fast/2016-August/000940= .html > > and patches due out tomorrow. It would be great fun to also start > fiddling with wireguard with this new stuff. I think the right thing - > now that you've found it - is to ape what the newer protocols do... > (and someone shoul fix linux ipsec) Excellent. I've just arrived in the mountains for a week and a half with my family, so I have limited access to hardware, but I am very interested in OpenWRT and WireGuard performance. Baptiste, a OpenWRT developer, hangs out= on this mailing list and got a WireGuard package in LEDE which is quite cool. That's excellent about a faster ath9k driver. --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org