[Bloat] What is fairness, anyway? was: Re: finally... winning on wired!

[Eric Dumazet]

Le mercredi 04 janvier 2012 à 10:25 -0500, Jim Gettys a écrit :

> As I read this thread, there are three questions that go through my mind:
>     1) since TCP is not "fair", particularly when given flows of
> different RTT's, how do we best deal with this issue?  Do either/both
> SFQ/QFQ deal with this problem, and how do they differ?

Main idea behind "fairness" is that one or few tcp flows are not able to
clamp the link (because peers are very close, RTT very small)

Its not "globaly fair" in the common sense.

QFQ is more complex, since you can classify your packets more precisely
than SFQ.

SFQ handles each "flow" the same than others in term of weight
(bandwith), and is light, while QFQ can permit you to give very fine
control but is also more difficult to setup (and apparently to debug...)

>     2) Web browsers are doing "unfair" things at the moment
> (unless/until HTTP/1.1 pipelining and/or SPDY deploys), by opening many
> TCP connections at the same time.  So it's easy for there to be a bunch
> of flows by the same user.  Is "fairness" better a per host property in
> the home environment, or a per TCP flow?  Particularly if we someday
> start diffserv marking traffic, I suspect per host is more "fair", at
> least for unmarked traffic.

By default, SFQ does a full flow classification (using hash on tuple
(src ip, dst ip, src port, dst port, proto...), but you can configure it
to only hash on dst ip. (or any combination)

Then, all 'users' behind a NAT will be considered as a single user.

Its "unfair"...


>     3) since game manufacturers have noted the diffserv marking in
> PFIFO-FAST, what do these queuing disciplines currently do?

SFQ doesnt care if used as the single qdisc on your device.

If you want/need such classification, a more complex setup is needed, to
separarate high prio trafic from 'other trafic'.