From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 8152B3B2A4 for ; Mon, 24 Apr 2017 08:08:55 -0400 (EDT) Received: by mail-wm0-x22b.google.com with SMTP id u65so21083070wmu.1 for ; Mon, 24 Apr 2017 05:08:55 -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=qjLtm2BNUCeeZ86LlFMbd9ZAgMV16XubTVX8acP+lr8=; b=lTf4puJXiqHmm+IANyQmgqGWxbwz28SDjHUroDFs4Kyx1V3U/SHtwjzAAfEpaqa3fi ONl4zSAEoUbJ1sNhL/LJ+j84yawlhY/imNnrXb2Au6g6YlIDMnwBwFqHDrnbGsYr6arU 5R1ucPKq7KsHxdROywTr2f8hTLWN1icz+POHVEffDX9G8H27B/iVOuyFLEWzNXsS4Cvw dIMGo3RT81t11+qd0G7EYqTCE8k9FX0VmBPzQD/8Xyqx8LvOGK9yaWvwmkCprmUfpI3Z yybtRj8LjP1917NCSzKtiLOooRwaDs9wEaZr/n876zw+sFzqJIYRwzPqrQL8SOYfCYv2 pITQ== 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=qjLtm2BNUCeeZ86LlFMbd9ZAgMV16XubTVX8acP+lr8=; b=jL4yB9bbqspKZjSdwhQBEK0VkfdF2A7tfKZ0rvv+wU62bE+PhGyr8mCjJwVuxR+PCb rFqVUyRIqLOCRg+U/91ERWcTLEJIeF/5ybexHTbindguyVTJG6FwBnYAUXWpEO+j8RJl ltWSI+5Wc8lwZD9pbhXvf2ix2Git9JPbB6hhWBeE1asUqhCynoGDY6ZKJXjjrPZdgCw1 a8dW52bhKVd8BXCuGfmviV/M09Hp0i60McljB8Itwgt8wG4fX5posTcaLYMcAl+ezN1K CMinUCCJgIGYAUHFr0cU55lfZnMDoZ2Ht+IJ35ci9Vf/U569rFPdwU6lRYU5HFSvqboA Tzzg== X-Gm-Message-State: AN3rC/6AqtrJmmfGr1BLrW3VXeNS9fOhORKKNNc8mKzpwWYzoDwz/N/t y9BT/CKylnuxgUlzGseOq6uqHbdhSg== X-Received: by 10.80.147.89 with SMTP id n25mr820566eda.69.1493035734204; Mon, 24 Apr 2017 05:08:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.169.59 with HTTP; Mon, 24 Apr 2017 05:08:53 -0700 (PDT) In-Reply-To: <8D8540DA-7AA3-4366-9488-DC1C266C598E@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> <8D8540DA-7AA3-4366-9488-DC1C266C598E@gmx.de> From: Dendari Marini Date: Mon, 24 Apr 2017 14:08:53 +0200 Message-ID: To: Sebastian Moeller Cc: David Lang , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=94eb2c1a8c189305fd054de878ab 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 12:08:55 -0000 --94eb2c1a8c189305fd054de878ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Could you share the two output plots somewhere, so I can have a look at > those? (Also I might want tto ask for the text file that actually was > generated by the ping collector script, just so I can run and > confirm/de-bug things my self). Sure thing. The plot images: http://imgur.com/a/qDtA0 And the output text file: https://drive.google.com/open?id=3D0B7vEuplJWEIkc1ozbUZRSGstajQ On 24 April 2017 at 13:34, Sebastian Moeller wrote: > Hello, > > > > On Apr 24, 2017, at 10:41, Dendari Marini wrote: > > > > 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? > > Hmm, 20 seems rather interesting and something I never saw before= . > Could you share the two output plots somewhere, so I can have a look at > those? (Also I might want tto ask for the text file that actually was > generated by the ping collector script, just so I can run and > confirm/de-bug things my self). I am not saying 20 is impossible, just th= at > it is improbable enough to require more scrutiny. > > > Best Regards > Sebastian > > > > > > 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 > 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 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 i= t > 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 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. > > > > > > 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 al= ways 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 > > > > > > --94eb2c1a8c189305fd054de878ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Could you share the two outpu= t plots somewhere, so I can have a look at those? (Also I might want tto as= k for the text file that actually was generated by the ping collector scrip= t, just so I can run and confirm/de-bug things my self).

Sure thing. The plot images:=C2=A0http://imgur.com/a/qDtA0 And the output text file:=C2= =A0https://drive.google.com/open?id=3D0B7vEuplJWEIkc1ozbUZRSGstajQ

On 24 Apr= il 2017 at 13:34, Sebastian Moeller <moeller0@gmx.de> wrote:
Hello,


> On Apr 24, 2017, at 10:41, Dendari Marini <dendari92@gmail.com> wrote:
>
> 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 https://github.com/moeller0/ATM_ove= rhead_detector and follow the instructions there...
>
> I just used your script and it estimated an overhead of 20 bytes, so s= hould I use "overhead 20 atm" or am I missing something? In the l= ast few days I've been using "pppoe-llcsnap" ("overhead = 40 atm") without any evident issue, should I change it?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hmm, 20 seems rather interesting and som= ething I never saw before. Could you share the two output plots somewhere, = so I can have a look at those? (Also I might want tto ask for the text file= that actually was generated by the ping collector script, just so I can ru= n and confirm/de-bug things my self). I am not saying 20 is impossible, jus= t that it is improbable enough to require more scrutiny.


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


>
> FWIW here's a quick example on ingress ppp that I tested using con= nmark
> the connmarks (1 or 2 or unmarked) being set by iptables rules on outb= ound
> connections/traffic classes.
>
> Unfortunately I'm really not sure how to apply those settings to m= y case, it's something I've never done so some hand-holding is prob= ably needed, sorry. At the moment I've limited the Steam bandwidth usin= g 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 th= ree 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 fo= r limiting Steam, what do you think?
>
> On 24 April 2017 at 09:55, Sebastian 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 kinda resolved I still feel like it's mainly related to Steam, as nor= mally downloading files from PC1 and PC2 halved the speed as expected even = at full bandwidth (so no overhead, no -15%).
> >>
> >>=C2=A0 =C2=A0 =C2=A0 This might be true, but for cake to meani= ngfully 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, yo= u probably won't notice unless you go looking)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Violent agreement. But note that with= AAL5=E2=80=99s rule to always 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 o= n 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 sacr= ifice seems excessive=E2=80=A6 But again you are right, there might be user= s who do not mind to go to this length. For this reason I occasionally reco= mmend to start the bandwidth at 50% to certainly rule out overhead/encapsul= ation accounting issues (mind you take 50% as starting point from which to = ramp up=E2=80=A6)
>
> Best Regards
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sebastian.
>
>
> >
> > David Lang
>
>


--94eb2c1a8c189305fd054de878ab--