From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7256D21F602 for ; Sun, 8 Nov 2015 08:50:01 -0800 (PST) Received: by oiww189 with SMTP id w189so65042089oiw.3 for ; Sun, 08 Nov 2015 08:50:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5POrf4zxuzxi24km1Ga7gAypsCPrbgSB4JrV4WeocRA=; b=0YLvr5sFu/dhJFfYjMCcRjF2QyXnf2a17w6jMzjmI/ELg5vlxAKJsptEUDrt6Oc3vG U5nzT/Dqa5ZiFRRM2VBurj5/D43PNrdND8jvG2z4WoWRmkZDQQr8WiZhHqCrZedB9Rgy zwlwK/DGcs9SjNY2At3I3agIjccV/BKB2NJX1BxdwjMm201kle1V0IfN2zcgpm276nhL NTRgSCgCONx4tvABsQb8u22ntKp8sKJr/eijGm94QhcIS1wtCkx02UrN67ZhSS/z0STI 5Vd13p+XICP5MZ6c0188dzqa8R4yusfdhiZ78qJwoAnrX3qa2vbit59mAdKFgLro06UY WzGA== MIME-Version: 1.0 X-Received: by 10.202.214.131 with SMTP id n125mr12310969oig.104.1447001400445; Sun, 08 Nov 2015 08:50:00 -0800 (PST) Received: by 10.202.61.133 with HTTP; Sun, 8 Nov 2015 08:50:00 -0800 (PST) Date: Sun, 8 Nov 2015 11:50:00 -0500 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net, Ken Rice , Randell Jesup , Harald Tveit Alvestrand Subject: [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 16:50:23 -0000 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=C3=A4ht 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 wr= ote: > >> On 8 Nov, 2015, at 12:19, Kevin Darbyshire-Bryant 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 =E2=80=9Cthreshold=E2=80=9D mechanism doesn=E2=80=99t imple= ment the priority queue at all, but only switches the underlying DRR weight= s between =E2=80=9Cpriority balance=E2=80=9D and =E2=80=9Cbandwidth balance= =E2=80=9D. Since it=E2=80=99s fundamentally DRR, and the weights of the qu= eues never go to zero, there is no possibility of starvation. Additionally= , the threshold mechanism itself =E2=80=9Cborrows=E2=80=9D bandwidth from l= ower 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 wa= nt tweaking, but it=E2=80=99s 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, ra= ther than the raw threshold value. > > - Jonathan Morton > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake