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

[Andy Furniss <adf.lists@gmail.com>]

Dendari Marini wrote:
> Hello, thank you all for your replies!
> 
> For the overhead I'm gonna use "pppoe-llcsnap" (or "overhead 40 atm),
> as I believe it's the one which should work best for my connection.

I seem to have confused my self as to whether you are using raw or not.

If you are not then I think that shaping on pppoe just overhead 40 atm
will be 22 bytes too little ....

Maybe what version of tc and or cake matters here, I don't know.

Maybe others could comment on that.

One simple test is set your up bandwidth just a little below your syn
rate and upload while pinging somewhere - if you are over then the pings
will rise.
In theory you should be able to run up almost at line rate - back off a
tiny bit to allow for LCP.
As you have a highly asymmetric connection you don't really want to
sacrifice more upload than is needed. A lot of your up bandwidth will be
needed just for acks.

> 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%).

Shaping too close to the real bandwidth is somewhat exposed more when
there are many connections involved.

> Anyway back to Steam: assuming the IP addresses aren't a big issue,
> what steps should I follow to start filtering its traffic so it's
> considered background? Would the DPI from the ER-X be any helpful?

It's a shame steam doesn't allow you to tell it to set tos/dscp like
some torrent clients do.

You could then use connmark to classify the incoming. Whatever method
you find to identify steam downloads it may be a bit hit and miss with
the dscp marking as on ingress you need to get tc to call iptables,
which seems to need a bit of luck with versions matching up properly.

Maybe on a pure router (ie. no significant traffic from wan to router)
you could consider shaping inbound traffic on the lan side.

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.

tc qdisc add dev ppp0 ingress
tc filter add dev ppp0 parent ffff: prio 1 protocol ip u32 match u32 0 0 
action connmark continue
tc filter add dev ppp0 parent ffff: prio 2 protocol ip handle 1 fw 
action xt -j DSCP --set-dscp-class cs1 action mirred egress redirect dev 
ifb0
tc filter add dev ppp0 parent ffff: prio 3 protocol ip handle 2 fw 
action xt -j DSCP --set-dscp-class cs4 action mirred egress redirect dev 
ifb0
tc filter add dev ppp0 parent ffff: prio 4 protocol ip u32 match u32 0 0 
  action mirred egress redirect dev ifb0

If you use ipv6 you would need to handle that as this is ipv4 only.