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

[Sebastian Moeller]

Hi Dendari,

> On Apr 24, 2017, at 15:49, Dendari Marini <dendari92 at gmail.com> wrote:
> 
> 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)

	The stair plot is quite nice, so 100 repetitions are suffficient, the issue is more that the size the hrping reports is not the same that gnu ping reports and hence thigns are off. So I still do not trust the 20 bytes report, but over all the data q\acquisition worked, I just need to figure out what hrping actually reports as “bytes” and then correct in the code accordingly. Weird, I believe I have a hrping dataset that worked correctly… 
Well scratch that hrping reports in its header:
with 16-160 bytes data (44-188 bytes IP):

so I need to handle hrping log files differently from normal ones (where I add the 20 + 8 IPv4 and ICMP header manually)… it seems that never worked correctly.. thanks for testing I will get back to you with an update later (this week)

Best Regards
	Sebastian





> 
> On 24 April 2017 at 14:35, Sebastian Moeller <moeller0 at gmx.de> wrote:
> Hi Dendari,
> 
> thanks,
> 
> 
> > On Apr 24, 2017, at 14:08, Dendari Marini <dendari92 at 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 at gmx.de> wrote:
> > Hello,
> >
> >
> > > On Apr 24, 2017, at 10:41, Dendari Marini <dendari92 at 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 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
> > >
> > >
> >
> >
> 
>