From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by huchra.bufferbloat.net (Postfix) with ESMTP id 6D9E421F2B9 for ; Wed, 18 Mar 2015 08:10:53 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 9D22B2005D81C; Wed, 18 Mar 2015 08:10:52 -0700 (PDT) Received: from kmnimac.local (c-50-156-111-45.hsd1.ca.comcast.net [50.156.111.45]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nichols@pollere.net) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 50E202005D807; Wed, 18 Mar 2015 08:10:52 -0700 (PDT) Message-ID: <5509957B.30600@pollere.com> Date: Wed, 18 Mar 2015 08:10:51 -0700 From: Kathleen Nichols User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: codel@lists.bufferbloat.net References: <7081A75C-899A-4DB7-8D77-935A37B362D8@gmail.com> In-Reply-To: <7081A75C-899A-4DB7-8D77-935A37B362D8@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Codel] The next slice of cake X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:11:21 -0000 Wow, this seems like great work! I'm curious about the statement about "tunes itself (that is, the target delay) to the bandwidth set on the shaper". How are you relating target delay to bandwidth? thanks, Kathie On 3/17/15 1:08 PM, Jonathan Morton wrote: > After far too long, it looks like I=E2=80=99ll have the opportunity to = work > on sch_cake a bit more. So here=E2=80=99s a little bit of a =E2=80=9Cs= tate of the > union=E2=80=9D speech about what we=E2=80=99ve got and what I=E2=80=99m= planing to add to > it. >=20 > So far we=E2=80=99ve got a deficit-mode, non-bursting shaper that works > pretty well, and an integrated implementation of fq_codel that tunes > itself (that is, the target delay) to the bandwidth set on the > shaper. The configuration is =E2=80=9Cas easy as cake=E2=80=9D; the in= tention is > that you can just specify one parameter (the bandwidth to shape at) > and leave everything else at the defaults; there simply aren=E2=80=99t = very > many visible knobs, because they aren=E2=80=99t needed. >=20 > We=E2=80=99ve also got Diffserv classification, and that part hasn=E2=80= =99t been so > successful. Each class grabs all traffic with some subset of the > codepoints, and stuffs them into a separate shaper+fq_codel instance, > and the higher-priority shapers steal bandwidth from the lower ones > to enforce priority. High-priority classes can only use a limited > amount of bandwidth, exactly as specified in generic Diffserv PHBs. >=20 > It works, perfectly as designed, but the resulting behaviour isn=E2=80=99= t > particularly desirable from an end-user perspective. In particular, > people run tests using best-effort traffic to see how much bandwidth > they=E2=80=99re getting, resulting in complaints that cake had to be gi= ven a > bigger number to get the correct throughput - which of course also > stops it from functioning correctly when background traffic is added > to the mix. So that needed a rethink. >=20 > Incidentally, the existing Diffserv implementation can be disabled by > specifying the =E2=80=9Cbesteffort=E2=80=9D keyword. This lumps all tr= affic into a > single class, handled by a single shaper at the configured rate. > Cake already works pretty well in that mode; sometimes I turn the > shaper down to analogue-modem speeds and note, with some > satisfaction, that everything *still* works. Except YouTube, but > that=E2=80=99s only because streaming video really does need more than > analogue-modem bandwidth. >=20 > As for performance, I=E2=80=99m able to make my ancient Pentium-MMX sha= pe at > over 50 Mbps, summing traffic in both directions between two bridged > Fast Ethernet cards. This limitation is probably a combination of > timer latency and context-switch overhead. I don=E2=80=99t expect it t= o > improve much, unless we find a way to seriously reduce those > overheads (which are already quite low for a modern desktop OS). A > faster machine with better timers gets better performance, of > course. >=20 > So there are two big things I want to change in the next version: >=20 > The easy part (at least in terms of how many unknowns there are) is > adjusting the flow-queueing part so that it uses set-associative > hashing instead of straight hashing when selecting a queue. This > should reduce the incidence of hash collisions considerably for a > given number of flow queues, or conversely provide equivalent > collision performance with a smaller number of queues. >=20 > The more interesting part is to rework the Diffserv prioritiser so > that it behaves more usefully. I think I=E2=80=99ve hit upon the right= idea > which should make this work in practice - instead of individually > hard-shaping each class, instead use the shaper logic as a threshold > function between high and low priority, and instead implement a > single shaper to handle all traffic. The priority function can then > be handled by a weighted DRR system - which is already in place, but > doesn=E2=80=99t do much - with just that small modification for changin= g the > weights based on the shaper state. >=20 > So high-priority traffic gets high priority - but only if it limits > itself to a reasonable bandwidth. Above that bandwidth, it gets low > priority, but is still able to use the full shaped bandwidth if > nobody else contends for it. And (unlike say HFSC) we need precisely > two parameters per class to do this, both specified as ratios rather > than hard bandwidth numbers: a bandwidth share (which determines both > the shaper setting and the low-priority-mode DRR weighting) and a > priority factor (which determines the high-priority-mode DRR > weighting). So if those knobs end up being exposed to userspace, > they=E2=80=99ll be easier to understand and thus use correctly. >=20 > All of this feeds my main goal with Diffserv, which is to start > giving applications natural incentives to mark their traffic > appropriately. Each class has both an advantage, and a tradeoff > which must be accepted to realise that advantage. If you need > absolutely minimal latency, you can choose a high-priority class, but > you=E2=80=99ll have to be frugal about bandwidth. If you need maximum > throughput, you=E2=80=99ll have to put up with reduced priority compare= d to > latency-sensitive traffic. And if you want to be altruistic, you can > choose to mark your stuff as bulk, background traffic, and it=E2=80=99l= l be > treated accordingly. All of this is in accordance with existing > RFCs. >=20 > A small caveat: cake is not designed for wifi. It=E2=80=99s designed f= or > links that can at least be treated as full-duplex to a close > approximation. Shared-medium links *can* behave like that, if > they=E2=80=99re shaped to a miserly enough degree, but we really need > something different for wifi - although several of cake=E2=80=99s compo= nents > and ideas could be used in such a qdisc. >=20 > Roll on cake3. >=20 > - Jonathan Morton >=20 > _______________________________________________ Codel mailing list=20 > Codel@lists.bufferbloat.net=20 > https://lists.bufferbloat.net/listinfo/codel >=20