[Cake] New to cake. Some questions

[Dennis Fedtke]

Hi Sebastian,

thank you for your answers :)

The ATM overhead detector script is currently running.
I read the wiki about it but im not quite sure how to interpret the plot.
I mean what info should i read from it? maximum packet size?
If yes do i set the overhead in cake? Or do i set iptables to clamp to 
new mtu/mss?

Regarding UDP paket dropping problem:
I just read some forums and users stated that under heavy load cake 
starts to drop udp packets which causes lag ingame.
My idea was to set ingress/egress to diffserv4 and apply the EF dscp 
mark on those packets.
Will this even work? if yes how to do this? iptables?

ipt -t mangle -A PREROUTING -p udp -m multiport --ports 5000:5500 -j 
DSCP --set-dscp-class EF

Like thia? Is prerouting correct here? (Taken from layer cake script)


For the squash and wash feature.
Im asking because if i choose to squash in the advanced options of sqm 
scripts.
The dscp fields/marks will be overwritten by iptables to 0 (besteffort). 
(layer cake script)
So then it makes no sense to manually set dscp fields/marks or? (Or even 
setting diffserv)

Did i understand this correctly. Per rfc isps should not provide dscp 
fields/marks?


Thank you.



Am 09.06.2016 um 23:30 schrieb moeller0:
> Hi Dennis,
>
> let me start with a disclaimer, I am not the best information source for cake on this mailing list, but I assume the others will chime in if I say something questionable…
>
>> On Jun 9, 2016, at 22:58 , Dennis Fedtke <dennisfedtke at gmail.com> wrote:
>>
>> Hi
>>
>> Currently im running lede + cake + sqm_scripts and i have some questions:
>>
>> 1. What is considered the “optimal" setup atm for cake?
> 	The same as without cake; really, proper per-packet-overhead accounting is important for bandwidth shaping, especially for ATM -based links. I would recommend to follow the method on https://github.com/moeller0/ATM_overhead_detector to m\empirically measure whether your link uses ATM encapsulation and what exact overhead is in use.
>
>> e.g. which cake script should i use piece or layer cake?
> 	piece_of_cake has only one tier of priority, while layer_cake currently offers 4. Packets are put into the different priority bands based on the content of their TOS/DSCP filed in the IP header; if this is greek to you, I guess piece_of_cake most likely is what you are looking for..
>
>> 2. Recently squash and wash was removed.
>> But the sqm scripts were not updated. In the advanced options should i set that the dcsp marks are kept?
> 	This really is an implementation detail that has no immediate effect if you choose piece_of_cake as typically only the bottleneck is sensitive to DSCP based priority banding. (Typically in that if you are unlucky your WLAN will use the DSCP marks to move packets into 4 different priority classes, which is fine if you want that, but bad for not sanity checked packets coming in from the wider internet (one is not supposed to assume incoming packets have sensible dscp markings as per RFC) that is why the wash/squash option is missed by some of us, independent of the fact that it was a layering violation).
>
>> 3. Should i use advanced options in sqm scripts and set triple-isolate + diffserv8 ?
> 	If you understand what these options do and believe that this is the best for your network go ahead, otherwise… The triple-isolate option will try to be fair to host_IP addresses first and then for each hostIP fair to each flow, but for that to do something you will most likely want this requires that cake sees internal IP addresses of your end-hosts. In the typical configuration with SQM on the WAN interface of a NAT router all internal addresses are replaced with the external IP address of the router it self and triple-isolates per host fairness will pretty much be equal to per flow fairness (not exactly, but in essence). So if you want to try tiple-isolate or its better defined brothers dual-srchost and dual-dsthost you would need to instantiate SQM on an internal interface like LAN. But then the direction of ingress and egress from the routers perspective changes with regards to the internet download and upload direction and you will need to put the internet upload bandwidth into the download field of the sqm GUI and vice versa. Also SQM on an internal interface will also shape internal traffic over the same interface, and that often affects traffic to and from the wifi/wlan radios to the lan switch… (I guess you would have preferred a shorter less vague response, but such are the constraints…)
>
>> 4. Is it recommend to enable diffserv on ingress?
> 	If you trust/konw/have confirmed that your upstream (ISP?) sends you sensible and reasonable DSCP markings by all means enable diffserv on ingress. But the default assumption should be that your upstream used a dscp mapping that only makes sense for them and not for you.
>
>> 5. Is there still the udp packet dropping problem? e.g. games that are using udp.
>> If yes does it make sense to apply diffserv classes manually? How to do this?
> 	I am not sure what you mean, but if you test this and have some findings please report here…
>
>> 6. is the autorate_ingress still under development?
>> This very interesting feature. especially for docsis networks. Will it be possible to set target ping time?
> 	The last tests did indicate that this feature is not ready for primetime at least not on typically fixed bandwidth links and I assume docsis links are fixed enough.
>
>> 6. What difference does it make to set a different rtt?
>> Setting lower rtt will reduce download speed i guess but will it allow better ping times (because of lower downloadrate uh)?
>> What happens if rtt is set way higher?
> 	With the RTT parameter you in essence specify how much time you give the endpoints of a flow to respond to a congestion signal (ECN marking or packet drop) if you select this way to small you will sacrifice bandwidth, if you set this too high you will accumulate more latency under load. The good thing seems to be that this does not need to be terribly precise, order of magnitude correctness seems to be sufficient (at least in base2)
>
>
>> Thank you!
> 	I am sure the real experts will also chime in…
>
> Best Regards
> 	Sebastian
>
>> _______________________________________________
>> Cake mailing list
>> Cake at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake