From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 0C88B21F3AC for ; Wed, 18 Nov 2015 09:30:50 -0800 (PST) Received: by lfaz4 with SMTP id z4so31372484lfa.0 for ; Wed, 18 Nov 2015 09:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s1DQJ3o97HT1NP9K5Uj5yI9ybMsiSSjqLfFeFnUMUv8=; b=GpRVW8U6tL8Tn0lss5wOZf88Uzy6LpQQG9TOoZLsyIkNlit1YZHcPP0ftwVlKI7ddc mkKNGgN2NqvM2ljKGjIln7pjtnDmjTVrAhleAQJwJIul9nilXjxiUYEmytW7zmMP/MsJ OxE/fpOgHe+vb9qQNgIDkD+AL0dXwdcZvDUb4InP8LnYD5+lJYl5l5MK6NCkb2X0jww3 AM1rIRsX2wsM/cqUnrK3Shv19+L2V/4fn6gr7R2qm+6O5HU4csovA2/PYxJd1SeAIbHa 50YPIoNJjOwm2rerrTib0tNvG2ruB25H2JC19RP9lsBVx/C3riir3hsGL/A+5VOgMg4E LkyA== X-Received: by 10.25.87.12 with SMTP id l12mr1310382lfb.97.1447867848077; Wed, 18 Nov 2015 09:30:48 -0800 (PST) Received: from bass.home.chromatix.fi (83-245-246-100-nat-p.elisa-mobile.fi. [83.245.246.100]) by smtp.gmail.com with ESMTPSA id au8sm567871lbc.31.2015.11.18.09.30.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Nov 2015 09:30:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Jonathan Morton In-Reply-To: Date: Wed, 18 Nov 2015 19:30:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <37A0F159-70F5-4FCF-B6FA-FE1D5DB9E6C4@gmail.com> To: Greg White X-Mailer: Apple Mail (2.3096.5) 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:31:13 -0000 > 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=E2=80=99s shaper doesn=E2=80=99t 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