From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 9FEA83B2A3 for ; Sat, 22 Apr 2017 18:15:46 -0400 (EDT) Received: from [192.168.1.222] ([80.135.73.48]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LcWSI-1cKUq63pCA-00jp6q; Sun, 23 Apr 2017 00:15:45 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 23 Apr 2017 00:15:44 +0200 Cc: Jonathan Morton , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <00DDAA0B-7D99-489B-BA2D-1F20289409B3@gmx.de> References: <05C0B0C7-4337-4115-AC6B-DA81392FCB34@gmail.com> <22E633CF-5EE0-4B0F-89A8-B790E730FB6C@gmx.de> <0BA3EE91-C5BC-4155-9D5D-D15D34490A1A@gmx.de> To: Dendari Marini X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:txCsU3WrXHkn/xxeoK1rFSGrSb2eobDDz9UV1Bk8mtEejo1QK6R rKkJNtPhsbYq9PNjPph63aHHv0lw48gQE+BtfH/oNQmPJhvuDuOEHMHrrKLmLUvrPsylg9W njXDSHGqTNl7fcpEfjswW5ufrH5gfQQX/r/wFt2JbMxBG4zgL//gR6KfwVFdC3cnGTImpLq QnjfbDeCbcsoTc0O9rVMA== X-UI-Out-Filterresults: notjunk:1;V01:K0:q1w4oFGxG6Q=:1fUhDy0TtsZF8fJzWQysdp Ba/Grh/g2JLtX7ke2f5NtStLi1gGSH1tqOkDRoazFe1SuwzFa4rPAVkVVJyKQykrnNHzIaKda pfDWdJ0XlctCrAHOsM0OlTJP7+wkB6vFXZpkKB1nXZzIkdMf1uYyp5mgcNZQ0W3VID7jnWv/J EJ6wyrR958skE2i/Gh/xUSXhEL04Ogm+Gu9BSC/oU8eIbXqt58jQjpe26Z1b0+e0JzOhebsQf nRHUtAk7y8NqvRVyibZeCe7f8MFke8Gh4liIC+AZWA2frW6jztOOxqSSn+61h5jSatnN9ao/w IpgzAMTk4hjXcFi4T4BM1vj7xwFKOyVN8IoitMCS/XYw48k7+BJ7rGlHB+hAGZpeqtZhKghxU tQsS3PhKnjHCtSJ7DcLIB9dr0pY8TNwGxmyOJphnfa3w5Kj2pK+Exl0BIhRsEvGhJEeeip3uR iP3ine4JC73t3GKNLPgeLzBOzwS8aoHjpgITC1ZmJqsotUY4o/5jAWLeBIRwVbChumZzrIQJa 6C2XP8IztCIxIocTzYGWdW5ITPWyvaKoqYfUnAUkg3HVJF2dbzlwpyrXg/NDEuPT1mAqveBkp 9aeV//UXswF+tkSiK8cBysZ1xyWKTz+6zWB90gKlA9IQFKSZgU1AmvrUXQYgSnJKsbV1WFUaz KwafJ0JIWJlJ5RdzaHjiTrGWQsQAhzX4b9nYoy7fmhBp6vgRiP4YqdrYQ4mjFQ+hLe/Q76wL6 rCcF80GGji2xNEePcuzRul7eD7tng04CWD6SKx22CpIItjHx3Bp7eS5yxY/KpPfTZQvx4fiJP Cx0nn+L Subject: Re: [Cake] Getting Cake to work better with Steam and similar applications 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: Sat, 22 Apr 2017 22:15:47 -0000 Hi Dendari, > On Apr 22, 2017, at 23:56, Dendari Marini wrote: >=20 > Hello, thank you all for your replies! >=20 > For the overhead I'm gonna use "pppoe-llcsnap" (or "overhead 40 atm), = as I believe it's the one which should work best for my connection. Probably correct, but you do not have to resort to believing, = you can actually try to measure that ;) In case I have been too subtle = before, have a look at https://github.com/moeller0/ATM_overhead_detector = and follow the instructions there... >=20 > About the per-host fairness download issue: while it's kinda resolved = I still feel like it's mainly related to Steam, as normally downloading = files from PC1 and PC2 halved the speed as expected even at full = bandwidth (so no overhead, no -15%). This might be true, but for cake to meaningfully resolve = bufferbloat you absolutely _must_ take care to account for encapsulation = and overhead one way or another. >=20 > Anyway back to Steam: assuming the IP addresses aren't a big issue, = what steps should I follow to start filtering its traffic so it's = considered background? Would the DPI from the ER-X be any helpful? Sorry, no direct experience so no practically applicable = recommendations. Best Regards >=20 > On 22 April 2017 at 18:47, Sebastian Moeller wrote: >=20 > > On Apr 22, 2017, at 11:36, Jonathan Morton = wrote: > > > >>> So please add =E2=80=9Catm overhead 32" to cake on eth0 or =E2=80=9C= atm overhead 40=E2=80=9D to cake instances on pppoe (these packets do = not have the PPPoE header added yet and hence appear 8 bytes to small). > >> > >> Thanks for your help, will definitely use them. Just wondering if I = use "pppoe-vcmux/bridged-llcsnap" on eth0 or "pppoe-llcsnap" on pppoe0 = would have the same effect? Or are there some other "under-the-hood" = changes when using them? > > > > On the pppoe interface, use pppoe-vcmux if your modem is set to use = VC-MUX, or pppoe-llcsnap if it=E2=80=99s set to use LLC-SNAP (they might = be described using slightly different terms, but should still be = recognisable as one or the other). This probably depends on your ISP, = and may further vary regionally within the same ISP. >=20 > In my experience it is rather bothersome trying to get that = information from one=E2=80=99s ISP, this is why I would recommend to = follow the instructions on = https://github.com/moeller0/ATM_overhead_detector and empirically = measure the actual overhead. In that case one ends up with the numeric = overhead, hence my inclination to use that number directly instead of = looking into a table to translate that back into a symbolic keyword=E2=80=A6= especially since say for an overhead of 32 (and 36) there are two = different encapsulation schees that add up to that number: >=20 > case 32 > disp('Connection: Bridged, LLC/SNAP RFC-1483/2684'); > disp('Protocol (bytes): Ethernet Header (14), ATM LLC = (3), ATM SNAP (5), ATM pad (2), ATM AAL5 SAR (8) : Total 32'); >=20 > disp('Connection: PPPoE, VC/Mux RFC-2684'); > disp('Protocol (bytes): PPP (2), PPPoE (6), Ethernet = Header (14), ATM pad (2), ATM AAL5 SAR (8) : Total 32=E2=80=99); >=20 > good luck divining which of those is in use if all you know is the = numeric overhead... >=20 >=20 >=20 > > > > I really prefer to use the self-explanatory keywords (which is why I = added them in the first place) instead of opaque magic numbers. This is = a point on which Sebastian has long disagreed with me. >=20 > True, but I am not going to re-hash that here again ;) >=20 > > > >>> Question: if you set the shaper=E2=80=99s to 50% of line rate = (8.75/0.5?) do you still see that unfairness? And if you add =E2=80=9Catm = overhead 40=E2=80=9D to cake on pppoe0 and set the shaper to 90% of line = rates (15.75/0.9) how does the Steam affect per-host fairness? Also how = transient are these connections team uses? > >> > >> Actually did more testing about this and it seems that as far I = have set the bandwidth to ~15Mbps (so ~15% less of my max speed) and use = the "nat" parameter, the per-host fairness works even without the = "dual-host" and "overhead" parameters. I definitely find this very = interesting, is this behaviour caused by the way Steam downloads games? > > > > By default, Cake uses triple-isolate mode, which uses information = about both source and destination hosts to perform per-host isolation; = this usually works well regardless of which side of the connection has = the LAN hosts. The =E2=80=9Cdual=E2=80=9D modes let you specify that = fact explicitly, making it a little more robust and predictable. > > > > Without overhead compensation, Cake will actually use more of the = physical link than it thinks it does - by default it only accounts for = raw IP or Ethernet packets, depending on the type of interface it=E2=80=99= s attached to. With full-size packets as in a bulk download, the = difference is relatively small, so the 15% margin is just about = sufficient to make things work. But with small packets mixed in, the = difference grows, such that Cake might no longer control the bottleneck = with some traffic mixes. >=20 > All true, to elaborate a bit on the ATM specific issue, due to = AAL5=E2=80=99s insistence that each ethernet frame is packaged into an = integer number of ATM cells (where the unused octets are simply padded = out) the worst case is something like 100%, if a hypothetical packet = would only require 49 Bytes, it will still require two ATM cells of 53 = bytes... >=20 > > > > The =E2=80=9Cconservative=E2=80=9D keyword I recommended earlier = (which is exactly equivalent to Sebastian=E2=80=99s recommendation of = =E2=80=9Catm overhead 48=E2=80=9D) reverses that situation; Cake will = then always end up using *less* of the physical link than it accounts = for, which is safe for troubleshooting with. The keyword is there = specifically so that we do=E2=80=99t have to figure out the precise = overhead profile before tackling more substantive issues. >=20 > Due to the boundary observation above, one other option is to = start with the shaper set to 50% of link rate, that should have = sufficient wiggle room for all realistic overheads=E2=80=A6 (but = honestly on a known ATM link I would always run the = ATM_overhead_detector to get the precise number). >=20 > > > > At any rate, it has nothing to do with Steam specifically. > > > >>> As far as I can tell cake can drill down to the required = IP/TCP/UDP fields independent of whether there are VLAN tags or PPPoE = headers so cake should not care (except for the different overhead = specifications you need to add as stated above). BUT if instantiated on = eth0 cake will see pppoe LCP packets and might decide to drop them, = which can take down the link, so out of caution I would still = instantiate on pppoe in your case. > >> > >> Yeah, with further testing it seems the interface wasn't the = culprit but I'll still do all my testing on pppoe0 just to be safe. > >> > >> Anyway I was wondering if there's some kind of manual for Cake and = the various parameters, I'm looking to set it up best way possible but = there are some parameters which I'm not sure what they do (one of them = being "ingress=E2=80=9D). > > > > With the correct version of iproute2 installed, just issue =E2=80=9Cma= n tc-cake=E2=80=9D. That=E2=80=99s the official documentation. > > > > Currently it doesn=E2=80=99t have the ingress keyword yet. = That=E2=80=99ll be fixed soon. > > > >> Also while reading on the bufferbloat.net Cake page I noticed a = possible "fix" for BitTorrent (by setting it as "background", = https://www.bufferbloat.net/projects/codel/wiki/Cake/#diffserv-support), = I'm wondering if this can be done with Steam too? > > > > It=E2=80=99s possible, if you can figure out which traffic is Steam = in the first place, and write filters to match on it. This is = complicated by the fact that Valve runs a sophisticated CDN to handle = their rather impressive bandwidth load. > > > > - Jonathan Morton > > >=20 >=20