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

[Kevin Darbyshire-Bryant]

On 08/11/15 16:36, Jonathan Morton 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.
I did say that I felt my coding was more an act of vandalism than
anything as well thought out as your code :-)

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

Oh absolutely.  Real numbers from real testing, couldn't agree more. 
It's very much needed (by people who actually understand what they're
looking at - rules me out)  I think there are two separate questions
that need looking at here:

1) In the presence of a full link, that link having competing 'full'
flows in all 'tins', then how should cake split the link in terms of
bandwidth?  Dave has argued there is not enough focus on 'Best Effort'
(tin 1) and too much focus on 'a bit better than best effort' (tin 2). 
Bulk (tin 0) I can't say I'm worried about.  'Voice' (low latency, low
jitter) (tin 3) we're hoping is also low bandwidth.  Without a full link
it arguably doesn't matter 'cos as you say we 'borrow' bandwidth from
the other tins to help out.  I pushed a tweak to the bandwidth weights
based on the insight you gave me ;-)  It might keep Dave happier (Bulk =
1/16th, Best Effort 8/16th, 'Better than best effort' 7/16th, 'Voice,
low latency & jitter' 2/16th)  Needs testing, needs numbers, based on a
*little* testing with flent it 'behaves' as per those allocations in the
presence of saturated link, saturating all tins.

2) With each increasing priority of tini[0-3], we decrease the
'expected' bandwidth (good) but also as a result increase the target and
interval.  Unless I've missed it, I've not yet seen an explanation at my
level (ie. idiot!) as to why that is the case.  The underlying link rate
doesn't change (it always runs at tin[0]) so it appears that we become
more tolerant of things sitting in and take longer to do anything about
it in tin[3]'s queue than tin[0].  I genuinely don't understand
why....and I'll assume my default position that it's 'cos I'm dumb
rather than an error in what I can see is carefully crafted code.  But I
do remain confused.


Kevin




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4816 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20151109/09d82fb9/attachment-0002.bin>