From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 E1C693B29E for ; Mon, 24 Apr 2017 04:41:14 -0400 (EDT) Received: by mail-wm0-x22c.google.com with SMTP id r190so6674718wme.1 for ; Mon, 24 Apr 2017 01:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1DT35irD8tEkONqca6aNv9P6boCsOvzaiaxh5OBPCgo=; b=TkZ+C+SS6C3k6HY2oNLC/AhKm2Di1QPTlognD8ANIULpaVzN4Y1dWM4CBcwlMj4UNw QE4Fu1WBFUYBFh23LKnelRdKE8LQGmkzv7wAAIbaEMjCuqMW0QEMBUYIFD0PLuYTZou0 5e2wgvUWU3x2RvmQEiQZcYj6hxUIJ9RBAvTwf9dcAJQn0C8lGBG0QP6rjxeJC7FLDtvR nAjhjByUnUQ16/0GifqlGbLUIukBtknPpBYrX50e6LFwKgiPLcjJeD300aakh5n4JKk5 dRaWy9fFOIgRb/r5iZHNfcofclYpG3CodLvbslfqrseTOUrw3gxwaQNabSpPKoMea/Ge HRAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1DT35irD8tEkONqca6aNv9P6boCsOvzaiaxh5OBPCgo=; b=JoO3l3Z2/6KIT4b9NmnzG0aZ7yIraDUbefVTxvZgBKwYI/5Mu4KYeiDgRXfGjBGYsi KR4CyLstTGmX5IpkBkrNZE2UoBF890zp9HIz96emaMKCZpSdHNUOIte6KFlS4XlOk9WF geA6amD6WZerQCvgkCh9EHB+gA0tHBhvcMgLXQiEFtUkp+6qmOEL5pvm1amLCDrk209F jWzcmnnoBk6LK04ePk1lQ4s3pMbak/oIUOkb2qbaSrLiaISazfXZxwaTizqAyFpeX1dR kIgSUOUkSoHohP28U3Lig6weSjTJaGf40Y3EVXDdzXC8uyc3EiQs8hD0EzAQ3xIdAuud mP9g== X-Gm-Message-State: AN3rC/4XjfrIgbB/PlgxSxq4IIOd0in2haDrhoKNanSs96+/LD1deZFH h63oMjK7uIZD9ZF1EDKj4TWOnRKNYQ== X-Received: by 10.80.164.241 with SMTP id x46mr172335edb.114.1493023273944; Mon, 24 Apr 2017 01:41:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.169.59 with HTTP; Mon, 24 Apr 2017 01:41:13 -0700 (PDT) In-Reply-To: <2FFBF256-2932-4FC7-AD1F-0D7CEE111809@gmx.de> References: <05C0B0C7-4337-4115-AC6B-DA81392FCB34@gmail.com> <22E633CF-5EE0-4B0F-89A8-B790E730FB6C@gmx.de> <0BA3EE91-C5BC-4155-9D5D-D15D34490A1A@gmx.de> <00DDAA0B-7D99-489B-BA2D-1F20289409B3@gmx.de> <2FFBF256-2932-4FC7-AD1F-0D7CEE111809@gmx.de> From: Dendari Marini Date: Mon, 24 Apr 2017 10:41:13 +0200 Message-ID: To: Sebastian Moeller Cc: David Lang , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=94eb2c0ddf48e28e97054de59104 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: Mon, 24 Apr 2017 08:41:15 -0000 --94eb2c0ddf48e28e97054de59104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, 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, ha= ve > a look at https://github.com/moeller0/ATM_overhead_detector and follow > the instructions there... I just used your script and it estimated an overhead of 20 bytes, so should I use "overhead 20 atm" or am I missing something? In the last few days I've been using "pppoe-llcsnap" ("overhead 40 atm") without any evident issue, should I change it? FWIW here's a quick example on ingress ppp that I tested using connmark > the connmarks (1 or 2 or unmarked) being set by iptables rules on outboun= d > connections/traffic classes. Unfortunately I'm really not sure how to apply those settings to my case, it's something I've never done so some hand-holding is probably needed, sorry. At the moment I've limited the Steam bandwidth using the built-in Basic Queue and DPI features from the ER-X. They're easy to set up but aren't really ideal, would rather prefer Cake would take care about it more dynamically. Anyway about the Steam IP addresses I've noticed, in the almost three weeks of testing, they're almost always the same IP blocks (most of which can be found on the Steam Support website, https://support.steampowered.com/kb_article.php?ref=3D8571-GLVN-8711). I believe it would be a good starting point for limiting Steam, what do you think? On 24 April 2017 at 09:55, Sebastian Moeller wrote: > Hi David, > > > On Apr 23, 2017, at 14:32, David Lang wrote: > > > > On Sun, 23 Apr 2017, Sebastian Moeller wrote: > > > >>> 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 bandwidt= h > (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. > > > > well, one way to account for this overhead is to set the allowed > bandwidth low enough. Being precise on this overhead lets you get closer = to > the actual line rate, but if you have enough bandwidth, it may not really > matter (i.e. if you have a 100Mb connection and only get 70Mb out of it, > you probably won't notice unless you go looking) > > Violent agreement. But note that with AAL5=E2=80=99s rule to alwa= ys use an > integer number of ATM cells per user packet the required bandwidth > sacrifice to statically cover the worst case gets ludicrous (theoretical > worst case: requiring 2 53 byte ATM cells for on 49 Byte data packet: 100= * > 49 / (53 * 2) =3D 46.2% and this is on top of any potential unaccounted > overhead inside the 49 Byte packet). Luckily the ATM padding issue is not > as severe for bigger packets=E2=80=A6 but still to statically fully solve > modem/dslam bufferbloat the required bandwidth sacrifice seems excessive= =E2=80=A6 > But again you are right, there might be users who do not mind to go to th= is > length. For this reason I occasionally recommend to start the bandwidth a= t > 50% to certainly rule out overhead/encapsulation accounting issues (mind > you take 50% as starting point from which to ramp up=E2=80=A6) > > Best Regards > Sebastian. > > > > > > David Lang > > --94eb2c0ddf48e28e97054de59104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

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=C2=A0https://github.com/moeller0/AT= M_overhead_detector=C2=A0and foll= ow the instructions there...

I just = used your script and it estimated an overhead of 20 bytes, so should I use = "overhead 20 atm" or am I missing something? In the last few days= I've been using "pppoe-llcsnap" ("overhead 40 atm"= ) without any evident issue, should I change it?

FWIW here's a quick example on ingress ppp that I tested using connma= rk
the connmarks (1 or 2 or unma= rked) being set by iptables rules on outbound
connections/traffic classes.

Unfortunately I'm really not sure how to apply those settings to= my case, it's something I've never done so some hand-holding is pr= obably needed, sorry. At the moment I've limited the Steam bandwidth us= ing the built-in Basic Queue and DPI features from the ER-X. They're ea= sy to set up but aren't really ideal, would rather prefer Cake would ta= ke care about it more dynamically.

Anyway about th= e Steam IP addresses I've noticed, in the almost three weeks of testing= , they're almost always the same IP blocks (most of which can be found = on the Steam Support website,=C2=A0https://support.steampowered.com/k= b_article.php?ref=3D8571-GLVN-8711). I believe it would be a good start= ing point for limiting Steam, what do you think?

On 24 April 2017 at 09:55, Sebas= tian Moeller <moeller0@gmx.de> wrote:
Hi David,

> On Apr 23, 2017, at 14:32, David Lang <david@lang.hm> wrote:
>
> On Sun, 23 Apr 2017, Sebastian Moeller wrote:
>
>>> About the per-host fairness download issue: while it's kin= da 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 fu= ll bandwidth (so no overhead, no -15%).
>>
>>=C2=A0 =C2=A0 =C2=A0 This might be true, but for cake to meaningful= ly resolve bufferbloat you absolutely _must_ take care to account for encap= sulation and overhead one way or another.
>
> well, one way to account for this overhead is to set the allowed bandw= idth low enough. Being precise on this overhead lets you get closer to the = actual line rate, but if you have enough bandwidth, it may not really matte= r (i.e. if you have a 100Mb connection and only get 70Mb out of it, you pro= bably won't notice unless you go looking)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Violent agreement. But note that with AA= L5=E2=80=99s rule to always use an integer number of ATM cells per user pac= ket the required bandwidth sacrifice to statically cover the worst case get= s ludicrous (theoretical worst case: requiring 2 53 byte ATM cells for on 4= 9 Byte data packet: 100 * 49 / (53 * 2) =3D 46.2% and this is on top of any= potential unaccounted overhead inside the 49 Byte packet). Luckily the ATM= padding issue is not as severe for bigger packets=E2=80=A6 but still to st= atically fully solve modem/dslam bufferbloat the required bandwidth sacrifi= ce seems excessive=E2=80=A6 But again you are right, there might be users w= ho do not mind to go to this length. For this reason I occasionally recomme= nd to start the bandwidth at 50% to certainly rule out overhead/encapsulati= on accounting issues (mind you take 50% as starting point from which to ram= p up=E2=80=A6)

Best Regards
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastian.


>
> David Lang


--94eb2c0ddf48e28e97054de59104--