From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-12-iad.dyndns.com (mxout-058-iad.mailhop.org [216.146.32.58]) by lists.bufferbloat.net (Postfix) with ESMTP id DBE222E06BA for ; Fri, 4 Feb 2011 10:55:01 -0800 (PST) Received: from scan-11-iad.mailhop.org (scan-11-iad.local [10.150.0.208]) by mail-12-iad.dyndns.com (Postfix) with ESMTP id 2AE1937163D for ; Fri, 4 Feb 2011 18:55:00 +0000 (UTC) X-Spam-Score: 0.1 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 75.145.127.229 Received: from gw.co.teklibre.org (75-145-127-229-Colorado.hfc.comcastbusiness.net [75.145.127.229]) by mail-12-iad.dyndns.com (Postfix) with ESMTP id 7442437164C for ; Fri, 4 Feb 2011 18:54:58 +0000 (UTC) Received: from cruithne.co.teklibre.org (unknown [IPv6:2002:4b91:7fe5:2:21c:25ff:fe80:46f9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cruithne.co.teklibre.org", Issuer "CA Cert Signing Authority" (verified OK)) by gw.co.teklibre.org (Postfix) with ESMTPS id CC85B5E936 for ; Fri, 4 Feb 2011 11:54:57 -0700 (MST) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id 205D4121B77; Fri, 4 Feb 2011 11:54:57 -0700 (MST) From: d@taht.net (Dave =?utf-8?Q?T=C3=A4ht?=) To: Juliusz Chroboczek Organization: Teklibre - http://www.teklibre.com References: <87k4hgdte9.fsf@trurl.pps.jussieu.fr> <87zkqbn896.fsf@cruithne.co.teklibre.org> <87wrlfd7eq.fsf@trurl.pps.jussieu.fr> Date: Fri, 04 Feb 2011 11:54:57 -0700 In-Reply-To: <87wrlfd7eq.fsf@trurl.pps.jussieu.fr> (Juliusz Chroboczek's message of "Fri, 04 Feb 2011 18:41:17 +0100") Message-ID: <874o8jmxz2.fsf@cruithne.co.teklibre.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] About Stochastic Fair Blue (SFB) 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: Fri, 04 Feb 2011 18:55:02 -0000 Juliusz Chroboczek writes: >> Also, would you mind if I also put the SFB code into git somewhere >> on github? It could use a few minor tweaks (make install). > > If that's okay with you, I'd like to commit it myself. Go right ahead! Just tell us where. > If you suggest the right repo to clone, I'll be glad to do it, and > you'll be able to merge it afterwards. My thought was, since there is an upcoming flurry of AQM modules, that it would be good to have a structure that allowed for them all to be maintained in a shared repository. So something like a Linux-AQM repo with a tree for each qdisc. They are highly modular so forking a Linux branch like Linux-wireless seems like overkill, at the moment. Thoughts? > >> 1) You can hash against multiple combinations of things. For example, in >> the home gateway scenario, you could hash against IP addresses only, not >> IP/port numbers - to give a per-device level of fairness. > > Stolen from esfq. Great artists steal! >> 3) It does packet marking... (So has to be used in combination with >> something else) > > I think you're confused -- it does ECN marking, not netfilter marking. The need for multiple levels of qdisc is that other protocols than TCP do not have ECN. > >> 1) I don't understand how the penalty box concept works. > > For each aggregate, sfb maintains a variable, called pdrop, which is the > drop probability for this aggregate; the more agressive a flow, the > higher pdrop. > > If the flow is inelastic, i.e. it doesn't slow down in reaction to > dropped packets, pdrop reaches 1. At that point, sfb should in > principle drop all the packets of this aggregate -- we say that this > aggregate has been put in a penalty box. > > (In my implementation of sfb, I'm not actually dropping all the packets > of inelastic flows, I'm just rate-limiting them drastically.) Thank you, that clears it up. >> 2) I don't understand how it would interact with shaping above and >> below it > > There's nothing below sfb, since it's a classless discipline. > > You may put anything you wish above sfb. If you're the bottleneck and > use a driver that performs proper backpressure, it's okay to put > nothing; otherwise, you need to put something to simulate backpressure, > typically tbf or htb. Except that other flows can be non-tcp - udp - sctp... Another "interesting" qdisc is hsfc. I know firsthand how badly different qdiscs can interact with each other.... > > --Juliusz -- Dave Taht http://nex-6.taht.net