[Cake] cake target corner cases?

[Sebastian Moeller]

Hi Alan,

On Nov 2, 2015, at 17:20 , Alan Jenkins <alan.christopher.jenkins at gmail.com> wrote:

> On 02/11/2015, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> Hi Alan,
>> 
>> On Nov 2, 2015, at 01:20 , Alan Jenkins <alan.christopher.jenkins at gmail.com>
>> wrote:
>> 
>>> I thought SQM works fine with mtu * 1.0.  But cake has been like this
>>> since at least April, and I didn't notice an extra 7ms when I tried
>>> it.  Confusing.
>> 
>> 	Well, sqm-scripts does take an MTU of 1540 bytes, which is less than ideal
>> because for ATM encapsulation the on wire size is actually 32 or 32 * 53, so
>> the worst case should be 33*53 = 1749 bytes, but in reality the actual limit
>> itself only needs to be approximately right.. That said, I guess I fixed up
>> sqm-scripts right now (by making target large enough for one 1749 byte
>> packet, I would be delighted if you could go measure whether this changes
>> things, before increasing auto-target to 1.5 worst case on-wire-packets, and
>> also scaling interval so that target <= 0.1*interval stays true)...
> 
> Ok.  Actually I wouldn't have measured +7ms because I wasn't testing
> cake flowblind, aka codel.  (And I was looking at ping under load, not
> tc -s qdisc, or the tcp rtf’s).

	Yes, you looked at the real data, the set-points is what I hoped to use to affect the real latency under load.

> 
> The increased target doesn't increase my bandwidth.  

	I believe we are talking changes so small it should not matter one way or the other, but then it is nice to be at least consistent with one’s own theory ;)

> Actually I'm
> failing to measure any changes at all, even for mtu*1.5.  I'm sure
> there's a real effect on buffering, if I had a less noisy way to
> measure it :(.  I couldn't work out exactly what you wanted testing;
> if there's something more specific I could probably spend more time on
> it.

	This is pretty much what I expected; the only interesting measurement left then is to disable this completely and see how a to small target affects latency under load… (I just wonder if this might be better measured with larger probe packets, say full MTU ICMP packets instead of small ones?)

> 
> I agree with the reasoning for 1749 bytes.  If you think mtu*1.5 is a
> good idea for SQM, I can't follow the logic, but it wouldn't bother me
> for fq_codel.  

	Oh, the 1.5 * 1749 is really just to be on the safe side, but until this setting makes a dent in at least one measurement, I guess I am not going to bother increasing this further; I will try to play with keeping interval at 20 to 10 times target though...

> I'm not really worried about cake, because I don't
> understand it.  cake flowblind with mtu*1.5 hard-coded sounds less
> good, but I don't have any reason to use it in that mode :).
> 
> 
>>> 	b->cparams.interval = max(rtt_est_ns +
>>> 				     b->cparams.target - ns_target,
>>> 				     b->cparams.target * 8);
>> 
>> 	I sort of cheated, I knew this was in the code, but I wanted to highlight
>> that we need a better description of what cake does to not confuse future
>> users, sorry for that.
> 
> I won't complain, I'm probably the one being obstructive here.

	Not at all; you are right with your analysis and I should have been less circumvent...

> 
> 
>>> Maybe this keeps the target/interval ratio from going too far over the
>>> recommended 10%.  Though that's not what CoDel says to do.
>>> 
>>> In the CoDel draft you just don't drop below 1 MTU.  You don't adjust
>>> target for the rate.  There's no suggestion to increase interval
>>> either.  It makes sense that long transmission times add to the
>>> expected rtt (SQM does this too).
>> 
>> 	I know, I believe that K. Nichols recommended to increase interval, and I
>> opted for the simplest additive increase (as effectively the expected RTTs
>> increase by the amount of transfer time, and for asymmetric links we can
>> ignore the faster direction mostly).
>> 	Looking at the rationale in the codel RFC I now believe that scaling would
>> be the right thing… in theory smaller target better preserves responsiveness
>> at a slightly higher bandwidth sacrifice, and with slow links I believe
>> responsiveness is more important; but then I wonder what is more responsive,
>> a higher target ratio with a (smaller) estimated reaction time (in first
>> approximation interval gives the time we allow sender and receiver to react
>> to our signaling) or the theoretical better target ratio with an
>> artificially increased interval. I guess that needs data...
> 
> Data always good.  AIUI the ratio is about how low you can set target,
> before the bandwidth reduction becomes painful.

	Yes, but also target sort of correlates with the median expected queuing delay under saturating load, so if target is too high latency suffers, not exactly what codel aims to fix...


> 
> I can imagine expected rtt increases e.g. in Tin 4, when it's
> de-prioritised because of exceeding the bandwidth threshold.  I don't
> see why it would increase by over 400ms, in the 1Mbit/s case you
> showed.

	Well, I am not sure that I fully understand whether cake is doing what it wants to do there in the first place, and I am also unsure if cake achieves its goal why it does that. I would be delighted if someone in the know could elucidate that for me…

Best Regards
	Sebastian


> 
> Regards
> Alan