>>>>> "tls" == Thor Lancelot Simon <tls%panix.com@localhost> writes: tls> http://www.thefengs.com/wuchang/blue/41_2.PDF 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