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

[Eric Dumazet <eric.dumazet@gmail.com>]

Le vendredi 06 janvier 2012 à 12:42 -0500, Jim Gettys a écrit :

> That's not how these queuing disciplines work, from what little I
> understand: I'll let Eric and Dave explain exactly what SFQ + QFQ etc.
> are doing.  I think the word "fair" is getting over-used/abused and can
> cause us all to have terminal confusion, since "fair queuing" in the
> research community has a specific meaning.
> 
> Eric, Dave, care to explain exactly what these queuing disciplines are
> doing, and how they differ?


Well, SFQ and QFQ are different, because in SFQ you cannot have
flexibility of QFQ. Typical use of SFQ is using rxhash and let the thing
do its best, while in QFQ you can use different weights per class and
setup a very complex setup.

But in the end, its FQ. With all pros and cons.

> 
> >
> > Since 2004, we now understand that fairness has to involve accounting
> > over time. That requires per-user state, which is not something you
> > can do, or that you need to do, within every queue. We should leave
> > fairness to separate code, probably on machines specialising in this
> > at the edge of a provider's network domain - where it knows about
> > users/customers - separate from the AQM code of each specific queue.
> 
> 
> In home routers we *are* at the very edge of the network (in fact beyond
> the ISP's domain in the case of cable), and that is the focus of the
> experiments that Eric and Dave have been doing.  And here we can afford
> to keep track of per-user state in those devices.  That some of these
> queuing disciplines have such nice effects on latency of many
> applications is gravy.
> 
> This is the point where we go from multiple *users* to the single
> *customer*, which is what you see from where you sit.
> 
> I think "fair queueing" (whatever fair means) is pretty orthogonal to
> AQM in general: we need AQM to keep the overall buffers from filling
> from elephant flows and running full, which is never good, and causes
> packet loss, which ultimately these queuing disciplines don't handle... 
> And AQM is probably all that is needed upstream of the customer,
> particularly since "fairness" is entirely in the eye of the beholder. 
> And we still need an AQM known to work presented with variable bandwidth
> :-(....
> 
> I think we're in agreement here.  And if not, this is the time to get
> everyone to understand and share terminology.
> 

I fully agree. We know for sure that a big part of the problem is at
host side, or the appliance right before it (typical ADSL box / Wifi AP)

With a _single_ TCP upload, we can have lockout and poor interactive
results, no matter of work Bob is going to do in the Provider network.

In our home routers, we serve a small amount of 'users', and we have
enough cpu power to make some classification and try to improve things
before packets leave the box and enter the ISP domain.