From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (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 29F4D21F306 for ; Sun, 12 Apr 2015 15:44:21 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so46354924lbb.2 for ; Sun, 12 Apr 2015 15:44:19 -0700 (PDT) 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 :content-transfer-encoding:message-id:references:to; bh=SmtPuHXJ0aB8KTWxMSvEbugH6+aGGRLbPLbls5rX9N0=; b=tV6ZfMoxoWorJ7IJ6LxKkxy2bnS+Ox6QHQy5J5NlnO7VsTg90X8QUFOZOf3Wz1L/Ip UMypcAC8cZ/1Vkul+oS3sz0IaHMu3lWK80D4C/2HJ2ffLlgDc7lqj6JFbWiCCmpdxY+z Nsq500PnAm30QlVWg8OMGMkFgFs6uo+q8PXritnGF+LCFXNraTrGOfgJyfu3S9irq30J FPYQc46O9Xkj+oPwZOTD4PmCbBUT1UaJheHYFwSd/HyTwv7ThZqY7fC2gRYQtxO/gPjF yl7ldM2ZfQx+zqAiZVCGWEhkXVU8XJ/tzn06E3IEb22iLnSftQJlqHli0KUUleXl8RTo GDUQ== X-Received: by 10.153.11.163 with SMTP id ej3mr2532218lad.105.1428878659335; Sun, 12 Apr 2015 15:44:19 -0700 (PDT) Received: from bass.home.chromatix.fi (87-93-27-145.bb.dnainternet.fi. [87.93.27.145]) by mx.google.com with ESMTPSA id ba4sm1261161lab.31.2015.04.12.15.44.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Apr 2015 15:44:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: Date: Mon, 13 Apr 2015 01:44:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <81A130E2-00C8-4141-BB10-823699DA7DD0@gmail.com> References: To: cake@lists.bufferbloat.net X-Mailer: Apple Mail (2.2098) Subject: Re: [Cake] cake exploration 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: Sun, 12 Apr 2015 22:44:50 -0000 Okay, lots of things to think about all at once. Cherry-picking: > 5) Byte Mode-ish handling >=20 > Dropping a single 64 byte packet does little good. You will find in > the 50 flow tests that a ton of traffic is acks, not being dropped, > and pie does better in this case than does fq, as it shoots > wildly at everything, but usually misses the fat packets, where DRR > will merrily store up an entire > MTU worth of useless acks when only one is needed. >=20 > So just trying to drop more little packets might be helpful in some = cases. >=20 > 6) Ack thinning. I gave what is conventionally called "stretch acks" a > new name, as stretch acks > have a deserved reputation as sucking. Well, they dont suck anymore in > linux, and what I was > mostly thinking was to drop no more than 2 in a row... >=20 > One thing this would help with is in packing wifi aggregates - which > have hard limits on the number of packets in a TXOP (42), and a byte > limit on wireless n of 64k. Sending 41 acks from > one flow, when you could send the last 2, seems like a big win on > packing a TXOP. >=20 > (this is something eric proposed, and given the drop rates we now see > from wifi and the wild and wooly internet I am inclined to agree that > it is worth fiddling with) >=20 > (I am not huge on it, though) Okay, dropping individual 64-byte packets does little good. But = transmitting 64-byte packets costs very little. On the gripping hand, = receiving and processing 64-byte packets is probably disproportionately = expensive; probably much of our forwarding CPU overhead is per-packet, = not per-byte. (This could be tested by reducing MTU and seeing how much = the CPU saturation threshold moves.) Here=E2=80=99s something important: ECE-Echo is carried on acks. As far as wifi is concerned, if you=E2=80=99ve got 42 acks from one flow = aggregating into one transmit opportunity, then I=E2=80=99d say that=E2=80= =99s a very rare and degenerate case. Maybe it happens occasionally on = real traffic, but it would be a transient condition - not occurring = continuously. So it only matters if there=E2=80=99s competing traffic = for the same station, and that=E2=80=99s something we can tackle a = different way. > 7) Macaddr hashing on the nexthop instead of the 5tuple. When used on > an internal, switched network, it would be better to try and maximize > the port usage rather than the 5 tuple in some cases. We=E2=80=99ve sort-of almost got that already with =E2=80=9Cdsthost" = mode. > Personally I do not think that the 8 way set associative has is what > wifi needs for cake, I tend to think we need to "pack" aggregates with > as many different flows as possible, and randomize how we packet > them... I think.... maybe=E2=80=A6. Wifi needs per-flow fairness on a per-station basis, ie. not hashing the = entire 5-tuple at once, but processing different parts of it separately. That=E2=80=99s potentially a good thing in the more general case, = actually; at the moment, with multiple hosts served by a single cake = instance, one user can outcompete another by simply using more flows. > 13) It might be possible to write a faster codel - and easier to read > by using a case statement on the 2 core variables in it. The current > code does not show the 3 way state machine as well as that could, and > for all I know there is something intelligent we could do with the 4th > state. Yes. Easier to read code may even turn out to be faster (for a variety = of reasons), and will certainly be easier for hardware folks to get = their heads around. - Jonathan Morton