Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: altqd port to other BSD

>>>>> "tls" == Thor Lancelot Simon <> writes:


thanks.  sounds interesting.  It looks almost configuration-free, like
it might be somewhat easy to map this to PF syntax in the same spot as
the 'red' and 'ecn' tags, if anyone cared.

   tls> (SFB seems to work much better for the traffic on parts of my
   tls> company's network than anything else)

you are mostly repeating yourself though!  I was looking more for why
it's better, and what it's better than (surely not ``everything'').
or at least what you're using it for.  I understand that maybe there's
no time to tell the story though.

Also, for anyone else lost in the TLA soup, SFB stands for
``Stochastic Fair Blue''---it's more or less the same thing as ``the
finished version of Blue.''

it looks like a flow-hashing scheme similar to the WFQ Cisco uses by
default on T1's, or to WFQ-RED, but designed with a focus on punishing
``unresponsive flows'' which would be:

  * anything multicast.

  * other UDP flows without application-layer congestion avoidance.

There was this idea in early fair queueing work that TCP stacks would
adapt to new fancy output queues by ruthlessly and cleverly trying to
grab more than their fair share of bandwidth away from other TCP
stacks that cooperated with the queueing.  AFAIK it turns out this
didn't happen---instead stuff like bittorrent and ``download
optimizers'' found it easier to grab an unfair share (and cause
congestion) by just _opening lots of separate TCP streams_, and SFB
will not help with that---like all this configless work it makes the
convenient presumption that a flow is the unit of fairness.

Attachment: pgp5nuf6MajXB.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index