[Cake] cake target corner cases?
alan.christopher.jenkins at gmail.com
Mon Nov 2 11:20:43 EST 2015
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>
>> 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
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
More information about the Cake