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

[Dendari Marini <dendari92@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7836 bytes --]

Hi Sebastian,

Did few quick tests using your recommendations and the results is still
"overhead 20". Plot: http://imgur.com/a/5c3iv Text:
https://drive.google.com/open?id=0B7vEuplJWEIkRVBhX2xGUmNUMVE (NOTE: I
used PINGSPERSIZE = 100 instead of 1000, as I didn't have much time)

On 24 April 2017 at 14:35, Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi Dendari,
>
> thanks,
>
>
> > On Apr 24, 2017, at 14:08, Dendari Marini <dendari92@gmail.com> wrote:
> >
> > 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
>
>         Okay, these _look_ reasonable on first sight...
>
>
> > And the output text file: https://drive.google.com/open?id=
> 0B7vEuplJWEIkc1ozbUZRSGstajQ
>
> …but this actually shows that 8.8.8.8 truncated the size of the ICMP
> responses (the runs of “bytes=92” in the log file also it only returned
> sizes from 44 to 92 so not exactly what we asked for). I would not really
> trust these results, even though the RTTs should be dominated by your slow
> egress link. Please redo these against a different ICMP target server (
> netperf-east.bufferbloat.net might do, depending on your location, that
> on is on the east coast of the U.S.). I have to admit, that the
> hrping/windows overhead extraction did not have much exercise so far and
> might be not be robust enough. I will have a look at your log file, but
> this really requires a different target server. In the unix script there is
> the following:
>
>
>     echo "To run measurements supply the TARGET IP address as first
> agument to ${0} this script."
>     echo "Use traceroute 8.8.8.8 to get a list of increasingly distant
> hosts, pick the first host out of your network (ideally the DSLAM)."
>     echo "Test whether the selected host responds to ping: 'ping -s16 -c 1
> target.IP.address.quad' : this needs to actually return non zero RTTs."
>     echo "If the hosts does not reply to the pings take the next host from
> the traceroute (moving closer to 8.8.8.8), repeat until you find a replying
> host."
>     echo "Once the main script is started have a quick look at the
> logfile, to see whether the RTTs stay close to the initial test RTT."
>     echo "If the RTTs have increased a lot, the PINGPERIOD might be too
> short, and the host might have put us on a slow path; either increase
> PINGPERIOD or try the next host..."
>     echo ""
>     echo "Here is the traceroute (might take a while):"
>     echo ""
>     traceroute 8.8.8.8
>     echo ""
>     echo "Alternatively you might try to use googles infrastructure by
> running: ${0} gstatic.com "
>     echo "Please note that gstatic.com might not return arbitrarily sized
> ICMP probes, so check the log file care-fully.”
>
> Which unfortunately does not appear in the windows script yet, but this
> still seems great advise, please note that at the time this was written,
> 8.8.8.8 still replied with “correctly”’ sized ICMP echo responses just like
> gstatic.com di initially, now both seem to truncate their responses. This
> is somewhat to be expected, but maybe somewhere along the path there is
> another server that will still respond properly...
>
>
> Best Regards
>         Sebastian
>
>
>
> >
> > On 24 April 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_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 that
> 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 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@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 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
> > >
> > >
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 9969 bytes --]