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

[Sebastian Moeller]

Hi Andy,

> On Apr 25, 2017, at 14:58, Andy Furniss <adf.lists at gmail.com> wrote:
> 
> Dendari Marini wrote:
> 
>> Also I have done some more testing, I was able to limit Steam connections just to one thanks to some console commands ("@cMaxContentServersToRequest" and
>> "@cCSClientMaxNumSocketsPerHost") and while the situation improved
>> (no more packet loss, latency variation within 10ms, but still seeing
>> ping spikes of ~50ms) it's still not what I'd consider ideal, which
>> would be like with any other download. So my guess is there's
>> something else going on other than just the multiple connections,
>> which are definitely big part of the problem but not the only thing.
>> Anyway these are my current settings for Cake and I've been using them for the last four days without issues:
>> *qdisc cake 8005: root refcnt 2 bandwidth 950Kbit diffserv3 triple-isolate nat wash rtt 100.0ms atm overhead 40 via-ethernet* *qdisc cake 8006: root refcnt 2 bandwidth 17500Kbit diffserv3 triple-isolate nat wash ingress rtt 100.0ms atm overhead 40 via-ethernet*
> 
> I still think that once via-ethernet appears you really need the raw
> parameter.

	Why? As far as I can tell the default mode is to adjust for the kernel auto-added overhead (which seems to be 14 bytes for pakets headed for an ethernet device and zero for packets headed for a ppp device). If he adds raw, the kernel willl make its additions silently…

Independent of that matter one needs to specify different overheads on ethN and pppeN interfaces simply as the packets on the pppoN interface have not yet been encpsulated and are 8 byte smaller than on the respective ethN interface. I am by now thoroghly confused, so I might have missed the subtleties in which either cake or my understanding is wrong.

> On egress ppp it likely subtracts 22 bytes on ifb that is
> attached to ingress ppp 14 bytes.

	My understanding is again that on pppoe devices the kernel adds zero bytes auto matically and attaching the ifb does not seem to change that?

> If you shape on real eth (eg. lan side) or ifb hooked from real eth then
> you shouldn't use raw.

	Ah, I thought that the non-raw mode inquires at the kernel what overhead it intends to account for silently and simply undoes that probably by changing the overhead passed to the kernel so that the sum of both match what the user requested?

> 
> Thinking about it, mostly you will luck into it not making any
> difference, so the test I suggested earlier won't work. The reason being
> that whether the overhead is 40 or 40 - 22 an MTU sized packet or an
> empty ack/single sack will end up the same due to atm. sack > 1 will be
> wrong as of course will be other traffic of certain sizes, so a
> carefully crafted test would be needed to show the issue.
> 
> Talking of acks/sacks 17500 vs 950kbit doesn't even have room for one
> sack per packet, though mostly there will be < 1 ack per packet.

Intersting, looking into this I learned that SACK can cause up to 40 bytes of TCP options added to the packet...

> 
> Depending on your sync rate 17500 may be too close for ingress.