From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-01-iad.dyndns.com (mxout-028-iad.mailhop.org [216.146.32.28]) by lists.bufferbloat.net (Postfix) with ESMTP id 8C46F2E04A9 for ; Wed, 23 Mar 2011 18:04:26 -0700 (PDT) Received: from scan-01-iad.mailhop.org (scan-01-iad.local [10.150.0.206]) by mail-01-iad.dyndns.com (Postfix) with ESMTP id D809C6DC32 for ; Thu, 24 Mar 2011 01:04:26 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 134.157.0.129 Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mail-01-iad.dyndns.com (Postfix) with ESMTP id 5DFE36D91F for ; Thu, 24 Mar 2011 01:04:26 +0000 (UTC) Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id p2O13pw5015801 ; Thu, 24 Mar 2011 02:04:04 +0100 (CET) X-Ids: 165 Received: from lanthane.pps.jussieu.fr (lanthane.pps.jussieu.fr [134.157.168.57]) by hydrogene.pps.jussieu.fr (Postfix) with ESMTPS id 09DF5C010C; Thu, 24 Mar 2011 02:03:50 +0100 (CET) Received: from jch by lanthane.pps.jussieu.fr with local (Exim 4.72) (envelope-from ) id 1Q2Yxp-0001ic-Rq; Thu, 24 Mar 2011 02:03:49 +0100 From: Juliusz Chroboczek To: Jonathan Morton References: Date: Thu, 24 Mar 2011 02:03:49 +0100 In-Reply-To: (Jonathan Morton's message of "Sun, 13 Mar 2011 03:40:03 +0200") Message-ID: <7imxklz5vu.fsf@lanthane.pps.jussieu.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Miltered: at jchkmail.jussieu.fr with ID 4D8A9877.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4D8A9877.000/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Thoughts on Stochastic Fair Blue X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 01:04:26 -0000 (I'm the original author of sch_sfb.) > Having read some more documents and code, I have some extra insight into > SFB that might prove helpful. Note that I haven't actually tried it > yet, but it looks good anyway. In control-systems parlance, this is > effectively a multichannel I-type controller, where RED is > a single-channel P-type controller. Methinks that it would be worthwile to implement plain BLUE, in order to see how it compares. (Of course, once Jim comes down from Mount Sinai and hands us RED-Lite, it might also be worth thinking about SFRed.) > My first thought after reading just the paper was that unconditionally > dropping the packets which increase the marking probability was suspect. > It should be quite possible to manage a queue using just ECN, without > any packet loss, in simple cases such as a single bulk TCP flow. Thus > I am pleased to see that the SFB code in the debloat tree has separate > thresholds for increasing the marking rate and tail-dropping. They are > fairly close together, but they are at least distinct. I hesitated for a long time before doing that, and would dearly like to see some conclusive experimental data that this is a good idea. The trouble is -- when the drop rate is too low, we risk receiving a burst of packets from a traditional TCP sender. Having the drop threshold larger than the increase threshold will get such bursts into our buffer. I'm not going to explain on this particular list why such bursts are ungood ;-) The other, somewhat unrelated, issue you should be aware of is that ECN marking has some issues in highly congested networks [1]; this is the reason why sch_sfb will start dropping after the mark probability has gone above 1/2. > the length of the queue - which does not appear to be self-tuned by > the flow rate. However, the default values appear to be sensible. Please clarify. > The major concern with this arrangement is the incompatibility with > qdiscs that can drop packets internally, since this is not necessarily > obvious to end-user admins. Agreed. More generally, Linux' qdisc setup is error-prone, and certainly beyond the abilities of the people we're targeting; we need to get a bunch of reasonable defaults into distributions. (Please start with OpenWRT, whose qos-scripts package[2] is used by a fair number of people.) > I also thought of a different way to implement the hash rotation. > Instead of shadowing the entire set of buckets, simply replace the hash > on one row at a time. This requires that the next-to-minimum values for > q_len and p_mark are used, rather than the strict minima. It is still > necessary to calculate two hash values for each packet, but the memory > requirements are reduced at the expense of effectively removing one row > from the Bloom filter. Interesting idea. --Juliusz [1] Aleksandar Kuzmanovic. The power of explicit congestion notification. In Proceedings of the 2005 conference on Applications, technologies, architectures, and protocols for computer communications. 2005. [2] https://dev.openwrt.org/browser/trunk/package/qos-scripts/