From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-14-iad.dyndns.com (mxout-024-iad.mailhop.org [216.146.32.24]) by lists.bufferbloat.net (Postfix) with ESMTP id 30B9E2E0297 for ; Sat, 12 Mar 2011 17:40:07 -0800 (PST) Received: from scan-12-iad.mailhop.org (scan-12-iad.local [10.150.0.209]) by mail-14-iad.dyndns.com (Postfix) with ESMTP id E799844B4B5 for ; Sun, 13 Mar 2011 01:40:06 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.215.171 Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com [209.85.215.171]) by mail-14-iad.dyndns.com (Postfix) with ESMTP id 7FCE144B1E7 for ; Sun, 13 Mar 2011 01:40:06 +0000 (UTC) Received: by eydd26 with SMTP id d26so1492754eyd.16 for ; Sat, 12 Mar 2011 17:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=nI2YXjzJH7fLQxmUskFTLXJxFlbS4mRYtBGZz3jSVko=; b=GhJ1RbgubZKkq9anIVDpeQs6JVNKCJ01l5OtrSkXFfBHnC6eMoHUKT+EGX0wXkJdp+ /F6qT6zGuhPkcrQTfz6Aq/KGZnLHfhApN0Xrsz8YuzErDyZ/aiOrNuE1xNCJxrF1QaUV ggZJEXpO0b7ft1HlRFDuipYvU2ssyKiL3gKJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=Sl7sGtyl61lF2CQ1bJ9fj7BrsOytuHXjECYwBVj9KB7oiOvGLsN/x5vIraV4jgwyWI iX32rp0VRdAqzQA8kGbeK9+fGTqZtt7NsPLF7IgPCem2cFNNdpdlrSIykaDvoHcSEngf HPHQXtF+7cD8mxejpiAjUsvA8GU3dXmWXWMoQ= Received: by 10.213.12.203 with SMTP id y11mr583316eby.78.1299980405687; Sat, 12 Mar 2011 17:40:05 -0800 (PST) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi [83.150.84.172]) by mx.google.com with ESMTPS id x54sm4710804eeh.5.2011.03.12.17.40.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2011 17:40:05 -0800 (PST) From: Jonathan Morton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Mar 2011 03:40:03 +0200 Message-Id: To: bloat@lists.bufferbloat.net Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [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: Sun, 13 Mar 2011 01:40:08 -0000 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. 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. My second observation is that marking and dropping both happen at the = tail of the queue, not the head. This delays the congestion information = reaching the receiver, and from there to the sender, by 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. Another observation is that packets are not re-ordered by SFB, which = (given the Bloom filter) is potentially a missed opportunity. However, = they can be re-ordered in the current implementation by using child = qdiscs such as SFQ, with or without HTB in tandem to capture the queue = from a downstream "dumb" device. 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. 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. - Jonathan