From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 45A6421F339 for ; Wed, 18 Nov 2015 09:40:36 -0800 (PST) Received: by obbnk6 with SMTP id nk6so39218075obb.2 for ; Wed, 18 Nov 2015 09:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZI89D5ZdqgJ4M9cPdbO/h0fLfY9FadujJ64cvFE/P4U=; b=KadPr8wjfykCF8DljaJeHVgpE7SJkq2GfoyP2rBp2DXCp1LvnH3NGmjpQUWT5L9btN MdEAHFnCM40kNWRJ8TK4ZYhZWqZprs+2XHvEr5oJBZu0JtUUyz1NKouq61G58Wh9U4qx GGXrt8YDPyCLYMG29XDHChh5UqAL1Mnr2OnsslA5hQdf2A/iYofCxeaZu7aX1uq/T8fe iO8XJX8i5ma0B71nnar0VE8GqQxeZR615Ab63NSafQTNkJaScKMF8uuDxRUi71ksNaa0 LlsKm2kvPpef2yA+upUvBGtnnCXpScOecxZ4tPBs9Rr/knZ8Nw7Zm/DvpHcvcl6T87Wr Ba0g== MIME-Version: 1.0 X-Received: by 10.60.76.42 with SMTP id h10mr1906750oew.13.1447868435758; Wed, 18 Nov 2015 09:40:35 -0800 (PST) Received: by 10.202.50.130 with HTTP; Wed, 18 Nov 2015 09:40:35 -0800 (PST) In-Reply-To: References: <37A0F159-70F5-4FCF-B6FA-FE1D5DB9E6C4@gmail.com> Date: Wed, 18 Nov 2015 18:40:35 +0100 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" , Greg White 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:40:59 -0000 On Wed, Nov 18, 2015 at 6:30 PM, Jonathan Morton wr= ote: > >> On 18 Nov, 2015, at 19:12, Greg White wrote: >> >> 2) you delay small packets to avoid the 1 MTU "burstiness" that the trad= itional 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 (an= d 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 severa= l 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 compl= ex. Committing them all at once is certainly not a win; they must still in= cur serialisation delay. > > Conversely, committing them at the properly scheduled times allows flow-i= solation to work better (especially in the not-uncommon case where new pack= ets arrive for another flow while the original series is still being dealt = with), and also ensures that the correct sequence of sojourn times is visib= le 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 point= er 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, woul= d actually complicate the algorithm as well as worsening its system-level p= erformance. > > - Jonathan Morton >