From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by huchra.bufferbloat.net (Postfix) with ESMTP id 12C2A21F394 for ; Wed, 18 Nov 2015 10:16:06 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id tAIIG58O007300; Wed, 18 Nov 2015 11:16:05 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 18 Nov 2015 11:16:05 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([::1]) by EXCHANGE.cablelabs.com ([::1]) with mapi id 14.03.0224.002; Wed, 18 Nov 2015 11:16:03 -0700 From: Greg White To: Dave Taht , Jonathan Morton Thread-Topic: [Cake] cake shaper vs leaky bucket algorithm Thread-Index: AQHRIfARME372g0Mi0eJhN0LveILIJ6iBJ0AgAB6kYCAAALAgP//lJEA Date: Wed, 18 Nov 2015 18:16:02 +0000 Message-ID: References: <37A0F159-70F5-4FCF-B6FA-FE1D5DB9E6C4@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.6.150930 x-originating-ip: [10.4.11.49] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <126BD91DC50EC141AECC4C6E89FDA7F0@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cake@lists.bufferbloat.net" Subject: Re: [Cake] cake shaper vs leaky bucket algorithm 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: Wed, 18 Nov 2015 18:16:29 -0000 Ok, sorry to have mentioned MTU! :) Actually, the textbook definitions of "leaky bucket as a queue" tend to start with policing/shaping on pps (or equivalently assuming that all packets are the same size), and then extend the definition to handle variable sized packets by using the MTU as the quantum of burstiness. So, in the comparison, add a third difference: 3) you eliminate any dependence on (or concept of) the network MTU -Greg On 11/18/15, 10:40 AM, "Dave Taht" wrote: >On Wed, Nov 18, 2015 at 6:30 PM, Jonathan Morton >wrote: >> >>> On 18 Nov, 2015, at 19:12, Greg White wrote: >>> >>> 2) you delay small packets to avoid the 1 MTU "burstiness" that the >>>traditional algorithm would create. > >I think dragging in MTU here is a problem. What we are seeing on most >new hardware is also "superpackets" from GRO/TSO/GSO offloads, where >inside the box up to 64k from a single stream is delivered as a single >unit. Where I see this now all the time is a 10 or 20 IW10 packet >"burst" coming into the router/modem from the gigE interface, needing >to get broken down into real packets and mixed into other flows at the >10 or 20Mbit uplink. > > >>> >>> Change 2 might be more debatable, since it adds latency where (it >>>could be argued) it isn't needed. The argument might be: if it is >>>acceptable (and it has to be) for the shaper to put an MTU worth of >>>consecutive bytes on the wire, does it matter whether those bytes are >>>one large packet or several small ones? >> >> When a large packet is committed for transmission, the latency it >>causes (due to serialisation) is unavoidable. > >I still wish we had 584 byte MTUs standard... > >> When a series of small packets are available, the situation is more >>complex. Committing them all at once is certainly not a win; they must >>still incur serialisation delay. >> >> Conversely, committing them at the properly scheduled times allows >>flow-isolation to work better (especially in the not-uncommon case where >>new packets arrive for another flow while the original series is still >>being dealt with), and also ensures that the correct sequence of sojourn >>times is visible to the AQM layer. >> >> But Cake=B9s shaper doesn=B9t treat sub-MTU packets specially in any cas= e; >>in fact, it is unaware of the MTU, and is entirely capable of handling >>multi-MTU-sized aggregates. It waits until the next transmission is >>scheduled, transmits the next available packet, then advances the >>pointer by the wire-time occupied by that packet. > >The other advantage (already in the doc, but perhaps needs to be >brought out more) - is that in the sqm-scripts, with htb+fq_codel, >we had to increase the htb pool (quantum) size as the bandwidth got >higher, which was error prone and entirely dependent on the >capabilities and load of the cpu involved. (I don't know if my scaling >actually ever got fixed right, either) > >cake, compensates, almost magically, for the interrupt response rate >and cpu capabilities relative to the load. It's also tons faster than >htb+fq_codel were, scaling to 100mbit on the same hardware that >struggled at 60mbit (faster... on the last benchmark series I ran - in >june - we have added a few features since).... > >Now, it kind of remains to be seen as to how to burn this into >hardware, there's some work on that, stalled out on funding.... > >am really happy with cake so far. :) > >> >> So treating packets of different sizes differently, as you describe, >>would actually complicate the algorithm as well as worsening its >>system-level performance. >> >> - Jonathan Morton >>