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

[Justin McCann]

On Wed, Jan 4, 2012 at 11:16 AM, Dave Taht <dave.taht at gmail.com> wrote:
>
> On Wed, Jan 4, 2012 at 4:25 PM, Jim Gettys <jg at freedesktop.org> wrote:
>
> >    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?
>
> The reason why QFQ was outperforming SFQ here
>
> http://www.teklibre.com/~d/bloat/pfifo_sfq_vs_qfq_linear50.png
>
> was because SFQ was  enqueuing the first packet of a new stream at the
> end of the existing streams.
>
> After eric moved the SFQ enqueue to head, the two started performing
> the same at light workloads.
>
> (keep in mind the comparison already to pfifo_fast - log scale)
>
> http://www.teklibre.com/~d/bloat/pfifo_fast_vs_sfq_qfq_log.png
>
> So, the net effect of either fq mechanism is that slower flows jump
> forward in the queue.
> RTT  is not really relevant. [1]

I must have misinterpreted the 'new flows' discussion on netdev. Are
these new flows in the sense of SYN/SYN-ACK, or new flows in the sense
of "don't have any packets in the queue(s) right now"?


> 1: the 'slower flows gain priority' question is my gravest concern
> (eg, ledbat, bittorrent). It's fixable with per-host FQ.

Meaning that you don't want to hand priority to stuff that is intended
to stay in the background? How does the classification work you've
been doing interact with these latest QFQ tests?

   Justin