From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id DFFA521F914 for ; Sun, 8 Nov 2015 13:31:19 -0800 (PST) Received: from hms-beagle.home.lan ([217.237.68.126]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LtJAR-1aaOl72FmV-012qE8; Sun, 08 Nov 2015 22:31:14 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 8 Nov 2015 22:31:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6B52D67F-AD48-4FAD-A6A9-32FA4F131DA0@gmx.de> References: To: =?windows-1252?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:MQVfq3WJ1s8nZ6Ll0is3A18o8XB9CeKv9BBoZ3ESHytTL3X9hwA qlZGn0qiNoXPjF14kW6N24okX6LnODjzJ2aIAeGTyTuCxidogO4PgrcoUPIsozrrm9/Oy55 HbgD+BL8lUqt5W9wtCaUvgwRfipUx3OpJTePG4ry10Ab7nin5xRTCYA7YkMHpFOODaWuMQ7 NvcYdngwg8JQg4P8ve1RQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:gO8/aeIiQPM=:+/+ye03EQ9zojLuaZ5StOz 7C0SkSxOPe3ZO8X6agHwAAsTdFtafhNZHlUIKiZpq+tzwPZFWDyJwIi9vzYVKS/x48U3wtXag k3+6BzPlid9Cd63Vw8sFF3nff/dbQnuBFsBP9C0BVXK8foNPpsCxqQT2qpbugDgc2q3mPSR2+ LHH3aihtmeZe4DfeVBa99hXV2gZxucrA7cw4EKEJotzc+TPgd7Q7JOWS1Nyh5ZQ/xqH73/x59 froPT7S+lPm1DkYWtQWm42RuZ/YPVwxqmxijtKBVbmJsDeVV3EiR8OEHu9G/y/YzYblyVpSum iBV9bEcuOZ1+Yus2bGXRzTcRiPt6t4JK7aEY+bRnbTjy3X0fcXz4ZGT4WwaOqDFjYJNy4E2ZQ jp/cd82chMplYSDAYT2AQyChbAqR/1AqAvwJa2OqmTPHAbWqN9l0r8EBjGZp69UPUxbftp23b AiUKY2vBLfij4x3IF5W8Fpnl9+WtFSN8Dka6pGIxpXNZLvyDa6KQa+42BYsxvr4F7dcd3rrOQ X1AUeTzk1/7jmr4nyKvrnQc7powL1Wz+JPzEhY2rzMtL1VIJ5PdDKWqh42bUPSYn42e3faVJ8 g9KMAiQi5TkrXTKGR2BaaG8GjYkRMaAGRhwrwY739s00EDWq2O1LWok/Z/kqCMg9vLJiMkXbl CQ3/SHZ1+7w4QlTKS2DwHUqKlXqWkad/VIE4dkkJ5jbr3jVJRss6/w7+aNiNpww/ZJL8Fgf2D EdfDsh8f67CIX1h5hpVeQbJZDFtzye6pUTVoAZO95CR8lmvJrwGv2q5hdtgNJ6gos204wQdQ2 T08PXPx Cc: cake@lists.bufferbloat.net, Ken Rice , Randell Jesup , Harald Tveit Alvestrand Subject: Re: [Cake] coping with diffserv and videoconferencing right X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 21:31:42 -0000 Hi Dave, On Nov 8, 2015, at 17:50 , Dave Taht 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. =46rom 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 = =93room=94 in that tier... >=20 > 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. >=20 > I have lost track of the relative weights sqm used, not that they were > correct either. CEIL=3D${UPLINK} PRIO_RATE=3D`expr $CEIL / 3` # Ceiling for prioirty BE_RATE=3D`expr $CEIL / 6` # Min for best effort BK_RATE=3D`expr $CEIL / 6` # Min for background BE_CEIL=3D`expr $CEIL - 16` # A little slop at the top So in simple.qos we dedicate <=3D33% for the highest priority, BE can = get >=3D 50% and BK will get >=3D 17%. Following your logic PRIO_RATE is = a bit high, on the other hand we only have 3 tiers... Best Regards Sebastian >=20 > I have always kind of figured on having a bunch of well defined, yet > evolving, models and a good default. >=20 > 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. >=20 > There was some discussion on this thread a while back. >=20 > https://www.ietf.org/mail-archive/web/rtcweb/current/msg15319.html >=20 > 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.... >=20 > Dave T=E4ht > Let's go make home routers and wifi faster! With better software! > https://www.gofundme.com/savewifi >=20 >=20 > On Sun, Nov 8, 2015 at 11:36 AM, Jonathan Morton = wrote: >>=20 >>> On 8 Nov, 2015, at 12:19, Kevin Darbyshire-Bryant = wrote: >>>=20 >>> 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. >>=20 >> Actually, the =93threshold=94 mechanism doesn=92t implement the = priority queue at all, but only switches the underlying DRR weights = between =93priority balance=94 and =93bandwidth balance=94. Since it=92s = fundamentally DRR, and the weights of the queues never go to zero, there = is no possibility of starvation. Additionally, the threshold mechanism = itself =93borrows=94 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. >>=20 >> It *is* possible that the per-tin choices of target and interval = might want tweaking, but it=92s 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. >>=20 >> - Jonathan Morton >>=20 >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake