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 BC7F121F339 for ; Wed, 18 Nov 2015 09:41:19 -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 tAIHfIOd003189; Wed, 18 Nov 2015 10:41:18 -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 10:41:18 -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 10:41:16 -0700 From: Greg White To: Jonathan Morton Thread-Topic: [Cake] cake shaper vs leaky bucket algorithm Thread-Index: AQHRIfARME372g0Mi0eJhN0LveILIJ6iBJ0AgAB6kYD//42YAA== Date: Wed, 18 Nov 2015 17:41:15 +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: 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 17:41:42 -0000 agreed. (and I hope you understand I was speaking of the black-box behavior rather than describing an implementation of it, your implementation approach is clearly the appropriate one) On 11/18/15, 10:30 AM, "Jonathan Morton" wrote: > >> On 18 Nov, 2015, at 19:12, Greg White wrote: >>=20 >> 2) you delay small packets to avoid the 1 MTU "burstiness" that the >>traditional algorithm would create. >>=20 >> 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. > >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 case;= 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. > >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 >