[Cake] Getting Cake to work better with Steam and similar applications

[Dendari Marini]

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_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 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 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=8571-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 <moeller0 at gmx.de> wrote:

> Hi David,
>
> > On Apr 23, 2017, at 14:32, David Lang <david at 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 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’s 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 on 49 Byte data packet: 100 *
> 49 / (53 * 2) = 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… but still to statically fully solve
> modem/dslam bufferbloat the required bandwidth sacrifice seems excessive…
> But again you are right, there might be users who do not mind to go to this
> length. For this reason I occasionally recommend to start the bandwidth at
> 50% to certainly rule out overhead/encapsulation accounting issues (mind
> you take 50% as starting point from which to ramp up…)
>
> Best Regards
>         Sebastian.
>
>
> >
> > David Lang
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20170424/a41c07b7/attachment.html>