[Cake] coping with diffserv and videoconferencing right

[Dave Taht]

Personally I think the weighting in "cake" should be far less towards
videoconferencing than it is currently in the diffserv4 cake model,
otherwise it will be abused. BE should account for at least 50% of the
total, to keep the majority of incentive for BE.

 The weighting should also be relative to bandwidth. - giving 1/4 to
voice on a 100mbit system is overkill.

I have lost track of the relative weights sqm used, not that they were
correct either.

I have always kind of figured on having a bunch of well defined, yet
evolving, models and a good default.

High on my list is to get some version of webrtc (in chrome or firefox
or freeswitch or jitsy) to actually use two tuples for voice and
video, and the associated diffserv markings, to see what happened
under test.  Also really wanted to explore (or at least know) the real
bandwidth and packet rate opus at the most optimium setting (48khz,
2.7ms latency) used for 1-6 channels of audio.

There was some discussion on this thread a while back.

https://www.ietf.org/mail-archive/web/rtcweb/current/msg15319.html

If there is some list (rmcat?) this is worth discussing on, it would
be good to know. Other people worth talking to to put together the
needed testbed also... would really like to re-open the ecn idea for
video again....

Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi


On Sun, Nov 8, 2015 at 11:36 AM, 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.
>
>  - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake