[Cake] More on 'target' corner cases - rate/target/interval confusion?

[Sebastian Moeller]

Hi Jonathan,


On Nov 8, 2015, at 17:36 , Jonathan Morton <chromatix99 at gmail.com> wrote:

> 
>> On 8 Nov, 2015, at 12:19, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> wrote:
>> 
>> Whilst I was there I also subtly tweaked the diffserv4 video tin
>> bandwidth allocation to 11/16ths rather than 3/4.  In combination with
>> voice (1/4) it meant that (theoretically) best effort could be
>> completely starved, let alone bulk - it doesn't seem to actually happen
>> in real life, but setting video to 11/16th & voice to 4/16th means that
>> there's 1/16th to be fought over between best effort and bulk - and best
>> effort as a result does seem to get a little bit more of a look-in in
>> the face of 'more important' competition.
> 
> Actually, the “threshold” mechanism doesn’t implement the priority queue at all, but only switches the underlying DRR weights between “priority balance” and “bandwidth balance”.  Since it’s fundamentally DRR, and the weights of the queues never go to zero, there is no possibility of starvation.  Additionally, the threshold mechanism itself “borrows” bandwidth from lower tins to serve higher ones - this is a holdover from an earlier version when there was indeed a separate hard shaper per tin.
> 
> It *is* possible that the per-tin choices of target and interval might want tweaking, but it’s probably best to have some hard data for the effects of doing that.  One possibility is that target should be tuned for the worst-case (minimum) bandwidth under maximally saturated conditions, rather than the raw threshold value.

	Interesting, in sqm-scripts I opted for only adjusting for the total link bandwidth to keep things simple; I always felt this needs reconsideration, so setting the target for each Tin seems reasonable. In sqm-scripts I just added the target increase (target - 5ms) to interval to avoid target >= interval, also I believe that if a full MTU packet takes Xms on the first hop the expected RTTs will be that amount larger compared to a normal/faster link. (So far we have looked at each direction independently, which probably is not fully correct, but at least for asymmetric links I hope we can just ignore one direction).
	I always argued that interval should be increased to keep the target to interval ratio close to the ideal. And I have pushed this idea on the cake list quite offensively ;) Looking at sch_cake and discussions with you, Kevin and Toke make me wonder whether, especially for low bandwidth Tins this is the right thing to do.
	Increasing interval will reduce the responsiveness of the shaper as it will wait longer for flows to react (even though most flows probably will react quickly, it will just take longer to reign in unresponsive flows), so for really slow links adjusting target and then multiply by 8 or 20 will lead to a rather sluggish controller? Increasing target/interval above 10% should simply sacrifice a bit more responsiveness-under-load for more bandwidth utilization? So both adaptation methods have the potential to counter-act cakes design goal. 
	What are the options besides:

1) target set to worst case for each Tin, keep interval at set interval or at target, what ever is larger
2) target set to account for the link’s MTU transfer time, keep interval at set interval or at target, what ever is larger

3) target set to worst case for each Tin, interval at set interval or 8*target, what ever is larger
4) target set to account for the link’s MTU transfer time, interval at set interval or 8*target, what ever is larger

5) target set to worst case for each Tin, interval at set interval plus target
6) target set to account for the link’s MTU transfer time, interval at set interval plus target

What are the relevant bandwidths to test this at?

Best Regards
	Sebastian

> 
> - Jonathan Morton
> 
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake