From: Juliusz Chroboczek <jch@pps.jussieu.fr>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Thoughts on Stochastic Fair Blue
Date: Thu, 24 Mar 2011 02:03:49 +0100 [thread overview]
Message-ID: <7imxklz5vu.fsf@lanthane.pps.jussieu.fr> (raw)
In-Reply-To: <AB70D849-EC48-438E-B009-E22223CAF5E2@gmail.com> (Jonathan Morton's message of "Sun, 13 Mar 2011 03:40:03 +0200")
(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/
next prev parent reply other threads:[~2011-03-24 1:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-13 1:40 Jonathan Morton
2011-03-24 1:03 ` Juliusz Chroboczek [this message]
2011-03-24 5:30 ` Dave Hart
2011-03-24 20:44 ` richard
2011-03-24 22:22 ` [Bloat] Packet drops, ECN and ECN+ [was: Thoughts on Stochastic Fair Blue] Juliusz Chroboczek
2011-03-25 19:22 ` Richard Scheffenegger
2011-04-03 16:35 ` [Bloat] Thoughts on Stochastic Fair Blue Juliusz Chroboczek
2011-04-03 18:03 ` Jonathan Morton
2011-03-24 11:59 ` Jim Gettys
2011-03-24 12:40 ` Jonathan Morton
2011-03-24 13:32 ` Eric Dumazet
2011-03-24 13:31 Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7imxklz5vu.fsf@lanthane.pps.jussieu.fr \
--to=jch@pps.jussieu.fr \
--cc=bloat@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox