Re: [Cake] cake target corner cases?

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

On 02/11/2015, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Alan,
>
> On Nov 2, 2015, at 01:20 , Alan Jenkins <alan.christopher.jenkins@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 rtt's).

The increased target doesn't increase my bandwidth.  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.

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


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

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.

Regards
Alan