[Cake] New to cake. Some questions

Fri Jun 10 10:05:11 EDT 2016

Hi Sebastian,

yes this is wired connection. As i stated my ping times always vary 
independently of target.
My ISP is overloaded in certain regions. So i assume they do some 
shaping/limiting on certain protocols (icmp for example)
Connection speed is 200/20 Mbit.
ISP is unitymedia which doesn't allow you to use your own hardware.
So actually i have to run my router behind theirs with exposed host 
enabled :<

Ping response:

ping -s 1400 -c 1 109.90.x.x
PING 109.90.28.1 (109.90.28.1) 1400(1428) bytes of data.
1408 bytes from 109.90.28.1: icmp_seq=1 ttl=253 time=11.6 ms

--- 109.90.28.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 11.677/11.677/11.677/0.000 ms

This looks good or?

Yes i am from germany. So you are from germany too?

Thanks for your time and help :)

Best regards
Dennis

Am 10.06.2016 um 15:02 schrieb moeller0:
> Hi Dennis,
>
>> On Jun 10, 2016, at 14:43 , Dennis Fedtke <dennisfedtke at gmail.com> wrote:
>>
>> Hi Sebastian,
>>
>> i used the default setting of 1000.
> 	Okay, that should work i assume unless you have a very fast link… What link at what ISP do you actually have?
>
>> But it seems that my isp is dropping icmp packets if there are exceeding some sending threshold.
> 	I would be amazed if they did, a sympotom of that would be rsate reduction to all ICMP probe flows independent of target host. If however you only see this with specific hosts it is very likely that that host rate limits its ICMP responses. In either case try another host further upstream. II think I has reasonable decent results with targeting 8.8.8.8, googles dns servers.
>
>> So there is a lot of none usable ping data.
> 	Again, try another host…
>
>> I increased the send delay to 50ms. 25 ms already shows dropped requests.
> 	That might also help, as long as you stay below their throttling rate the chosen host might still work okay.
>
>> This is the third run now. Waiting for completion.
> 	Well, sorry that the method is not as slick and streamlined, but there are no guarded good ICMP reflectors available on the net.
>
>> The ping target is my first hop.
> 	Try the next hop then ;)
>
>> Actually my ping always varies around +-5ms even at idle and independently of ping target.
> 	This is via wifi/wlan? If so try from a wired connection instead.
>
>> When i look through the ping file the increase in ping times are actually appear to be random to me.
> 	Well, we expect variability of the individual “trials” to exist, that is why we collect so many and try to select the best measure in the matlab code to remove the unwanted variance. Could you post a link to both of the generated plots please, the first one showing te different aggregation measures might be helpful in diagnosing the issues deeper.
>
>> So how to test if my isp responses with fixed icmp packet size?
> 	You could try manually. In the folloewing example I pinged gstatic.com (which belongs to googles CDN as far as I know):
>
> bash-3.2$ ping -s 1 -c 1 gstatic.com
> PING gstatic.com (216.58.213.195): 1 data bytes
> 9 bytes from 216.58.213.195: icmp_seq=0 ttl=55
>
> --- gstatic.com ping statistics ---
> 1 packets transmitted, 1 packets received, 0.0% packet loss
>
>
> bash-3.2$ ping -s 64 -c 1 gstatic.com
> PING gstatic.com (216.58.213.195): 64 data bytes
> 72 bytes from 216.58.213.195: icmp_seq=0 ttl=55 time=19.446 ms
>
> --- gstatic.com ping statistics ---
> 1 packets transmitted, 1 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 19.446/19.446/19.446/0.000 ms
>
>
> bash-3.2$ ping -s 65 -c 1 gstatic.com
> PING gstatic.com (216.58.213.195): 65 data bytes
> 72 bytes from 216.58.213.195: icmp_seq=0 ttl=55 time=21.138 ms
> wrong total length 92 instead of 93
>
> --- gstatic.com ping statistics ---
> 1 packets transmitted, 1 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 21.138/21.138/21.138/0.000 ms
> bash-3.2$
>
>
> bash-3.2$ ping -s 1400 -c 1 gstatic.com
> PING gstatic.com (216.58.213.195): 1400 data bytes
> 72 bytes from 216.58.213.195: icmp_seq=0 ttl=55 time=6.878 ms
> wrong total length 92 instead of 1428
>
> --- gstatic.com ping statistics ---
> 1 packets transmitted, 1 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 6.878/6.878/6.878/0.000 ms
>
> Once I try to send 65 Bytes of ICMP payload the response is cut short to 92 bytes, the same might happen with your isp. But also if all your ISP does is rate limiting the ICMP packests that still can lead to to much variance in the RTTs…
>
>
>> Im in central europe too :D
> 	Ah, then you just have a different work/sleep cycle than I do ;). Where in central Europe, if I might as Ii am, as you might have guessed based in Germany…
>
> Best Regards
> 	Sebastian
>
>> Thanks :)
>>
>>
>> Am 10.06.2016 um 07:20 schrieb moeller0:
>>> Hi Dennis,
>>>
>>>
>>>> On Jun 10, 2016, at 02:49 , Dennis Fedtke <dennisfedtke at gmail.com> wrote:
>>>>
>>>> Hi Sebastian,
>>>>
>>>> Sorry this is positive or?
>>> 	I would say that is unclear…
>>>
>>>> But i need more samples ?
>>> 	I would try with more samples, after checking that the ping times in the recorded data file actually are larger for larger probes than for smaller, some hosts will reply with a fixed maximum ICMP packet instead of returning the received packet, thereby reducing the signal range (as only the upload leg of the link is meaning fully contributing useful differential signal.
>>> 	BTW I am in central europe so at times of the day my responses can be very sporadic, as I either am at work or sleeping ;)
>>>
>>> Best Regards
>>> 	Sebastian
>>>
>>>> Thanks :)
>>>>
>>>>
>>>> Am 10.06.2016 um 01:11 schrieb moeller0:
>>>>> Hi Dennis,
>>>>>
>>>>>> On Jun 10, 2016, at 00:45 , Dennis Fedtke <dennisfedtke at gmail.com> wrote:
>>>>>>
>>>>>> 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?
>>>>> 	The relevant number is reported as “Estimated overhead preceding the IP header” in the top part of the second figure created by the script. But that is only relevant.useful if you see a nice step like plot in figure 2 as well ( the second figure in https://github.com/moeller0/ATM_overhead_detector/wiki as positive and the fourth figure as negative example.
>>>>>
>>>>>> If yes do i set the overhead in cake? Or do i set iptables to clamp to new mtu/mss?
>>>>> 	If you use plain cake and you know the numerical overhead (NN) the easiest is to add the following to your cake invocation: “atm overhead NN”
>>>>>
>>>>> Please note that if you use cake on an ethernet interface the kernel will already account for 14 byte of ethernet overhead, so if the script told you 44 as actual overhead, you use ”overhead 30” to address that. If you use a pppoe interface the kernel will most likely not add the 14 bytes for you, so then you would use “overhead 44” (I excluded the atm option in the last examples for clarity…)
>>>>>
>>>>>> 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.
>>>>> 	Ell, not a bad idea, but often the problem are in the incoming traffic, and unfortunately with the ifb we use we can not use iptables, but only tc, and remarking with tc is unpleasant.
>>>>>
>>>>>> Will this even work? if yes how to do this? iptables?
>>>>> 	No, you wuld need tp use tc.
>>>>>
>>>>>> 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)
>>>>> 	This will affect outgoing packets and might be a good idea in your specific case.
>>>>>
>>>>> BUT why don’t you try the default behaviour with specific rules and tricks and report success or failure back to us, after all the fastest/easiest classification is one one does not need to perform at all.
>>>>>
>>>>>> 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)
>>>>> 	No unfortunately on ingress cake sees the packets before iptables, so the effective behavioral emulation of wash/squash by cake is to set ingress cake to besteffort (basically cake ignores the dscp field which functionally is identical to all packets having the same value). The squashing by iptables just clears the dscp marls so that internal networking elements like potentially wifi liknks are not confuzed by the dscp information.
>>>>>
>>>>>> Did i understand this correctly. Per rfc isps should not provide dscp fields/marks?
>>>>> 	Not exactly, per RFC DSCPs are only ever valid/defined inside a DSCP domain and your ISPs domain ends before it reaches your CPE. Since you have no control over your ISPs markings, they can be very much not like you want them to be (Dave That reported that his ISP re-mapped almost 1/3 or so of packets into the CS1 background class). So it is recomended that each DSCP domain re-mapps the code points at its entry point, which in your case is your router…
>>>>>
>>>>> Best Regards
>>>>> 	Sebastian
>>>>>
>>>>>> 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
>>>>>> _______________________________________________
>>>>>> Cake mailing list
>>>>>> Cake at lists.bufferbloat.net
>>>>>> https://lists.bufferbloat.net/listinfo/cake
>>