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

[Jim Gettys]

On 01/04/2012 11:16 AM, Dave Taht wrote:
>
>    3) since game manufacturers have noted the diffserv marking in
> PFIFO-FAST, what do these queuing disciplines currently do?
> They pay no attention to diffserv. It's possible we have a small
> problem here, but I'd wager not.

That's not what I understand from talking to Andrew McGregor: he says
the game companies have figured out that diffserv marking is respected
by PFIFO-FAST, and are marking appropriately (since most current routers
are doing PFIFO-FAST, as it's been the default in Linux for quite a while.

But the flows may be sparse enough it may not matter so much.

I think we need to understand this in more depth...

>
> If their packets are not saturating the link, and/or it's per
> host FQ, they are going to win.
>
> isochronous flows (like voice, even (especially) skype) should respond well to
> this stuff, too. do, actually. skype is nicer now.
>
>
> footnotes:
>
> 1: the 'slower flows gain priority' question is my gravest concern
> (eg, ledbat, bittorrent). It's fixable with per-host FQ.
>
> 2: I note that identifying "a host" is harder than it was in nagle's
> day - with multiple protocols in use a hash against an IP address is
> not accurate, nor, by the time you hit the egress interface, do you
> have a mac address to use.
>
> I did not solve that problem in my home router gw/aqm/fq prototype.
> The approximation was a hash that matched an ip or ipv6 address.
>
> 3: (and conversely, existing elephants slow down). (and when you drop
> packets there is a good question, but you do end up with classic tail
> drop behavior in both QFQ and SFQ on a per flow basis. You can get
> head drop out of QFQ, actually)
>
> 4: especially in variable bandwidth scenarios, the depth of even the
> fairest queue needs to be managed somehow.
>
> But I can live with the nearly two orders of magnitude of basic
> latency improvement we've got now, as well
> as the probability this induces of doing smarter/effective queue
> length management, and keep getting the bugs out of it....
>
>>
>
>