[Cake] coping with diffserv and videoconferencing right

[Sebastian Moeller]

Hi Dave,

On Nov 8, 2015, at 17:50 , Dave Taht <dave.taht at gmail.com> wrote:

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

Well, videoconferencing is really just a name, if you do not take it too literal all should be fine. From a social engineering point of view, I believe making this Tin the new normal is a reasonable thing to do, people/app developers need to be rewarded for doing the right thing (using DSCP markings). Marking will only ever work to solve the BT problem if we get BK separated from the rest. We could either hope that everybody will implement/use CS1 for BK data (I believe that so far bit torrent clients do not mark their packets at all) or we can make CS0 the new BK and move everything that cares one tier higher. For that to work we need an incentive (which lower latency should supply) and enough “room” in that tier...

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

	Again voice is just a name; on the other hand I agree with you that the highest tier should be relatively small so people will stay in whatever BE tier we come up with.

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

    CEIL=${UPLINK}
    PRIO_RATE=`expr $CEIL / 3` # Ceiling for prioirty
    BE_RATE=`expr $CEIL / 6`   # Min for best effort
    BK_RATE=`expr $CEIL / 6`   # Min for background
    BE_CEIL=`expr $CEIL - 16`  # A little slop at the top

So in simple.qos we dedicate <=33% for the highest priority, BE can get >= 50% and BK will get >= 17%. Following your logic PRIO_RATE is a bit high, on the other hand we only have 3 tiers...

Best Regards
	Sebastian

> 
> 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
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake