Re: [Cake] cake target corner cases?

[Sebastian Moeller <moeller0@gmx.de>]

Hi Alan,

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

> On 01/11/2015, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>> 
>> Can't give full explanation now but the bytes per ns calculation which is
>> used as a basis for target on 'slow' links uses mtu*1.5
>> 
>> --
>> Cheers,
> 
> Right.  And mtu*1.5 matches better than my math, if I look at Sebs
> figures again.  Oops :).
> 
> 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)...

> 
> Sebs 12.5% is indeed 1/8th.  (See last line).
> 
> 
> 	u32 byte_target = mtu + (mtu >> 1);	/* MTU * 1.5 */
> ...
> 	byte_target_ns = (byte_target * rate_ns) >> rate_shft;
> 
> 	b->cparams.target = max(byte_target_ns, ns_target);
> 	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.

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

> I can't see what the justification
> is for `target * 8` though.  If there's a good reason maybe it could
> use a comment.

	I fully agree, and hopefully not only in the code but also in the man page as that has potential to confuse users if not documented (and even if in the man page it will still cause confusion at least we can say RTFM ;))

Best Regards
	Sebastian

> 
> Thanks
> Alan