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

[Bob Briscoe]

Jonathan,

At 20:34 06/01/2012, Jonathan Morton wrote:

>On 5 Jan, 2012, at 7:52 pm, Bob Briscoe wrote:
>
> > The LEDBAT/BitTorrent issue wouldn't be fixed by per-host FQ.
> > LEDBAT/uTP tries to yield to other hosts, not just its own host.
>
>According to the LEDBAT I-D 
>(https://datatracker.ietf.org/doc/draft-ietf-ledbat-congestion/?include_text=1), 
>they expressly considered the effect of AQM and FQ, and considered 
>that even if they defeated the LEDBAT mechanism itself, it didn't 
>matter because they would achieve the LEDBAT *goal*.

Yup, I was involved in the ML wordsmithing of that. You've subtly 
changed the sense by altering the words: The draft says "achieving an 
outcome that is in line with LEDBAT's goals", which is not the same 
as "achieving LEDBAT's goals [in full]".

>That goal is to avoid starving other flows, *not* to ensure that 
>LEDBAT flows would always be starved by others.

But a goal of LEDBAT *is* to temporarily yield to interactive flows. 
FQ trumps LEDBAT and prevents it achieving this goal.

> > In fact, in the early part of the last decade, the whole issue of 
> long-running vs interactive flows showed how broken any form of FQ was.
>
>Wait, WTF?  Isn't the long-running versus interactive problem 
>precisely what FQ *does* solve, by prioritising sparse flows over dense ones?

Nooo. Pure FQ doesn't prioritise it equalises (instantaneous 
bit-rate). Cisco's WFQ does give a very short period of extra 
scheduling priority at the start of a flow. But that is a tiny effect 
compared to what would be required for true fairness /over time/.

>We do need both per-flow and per-user fairness.

No. One precludes the other - you can't have both. We need per-user 
fairness, which requires very unequal bit-rates per flow. The more 
that per-flow fairness is enforced in each queue, the harder it will 
be to remove it from the Internet to get per-user fairness.

See "Flow Rate Fairness: Dismantling a Religion" 
<http://dl.acm.org/citation.cfm?id=1232926>

For the avoidance of doubt, if anyone thinks "per-user fairness" 
means equal bit-rate per user, that's not what I take it to mean. I 
mean fairness /over time/. Not equality only at each instant, which 
doesn't take account of the huge benefit from a user staying inactive.

>SFQ and QFQ aim for per-flow fairness, as currently 
>implemented.  Providers currently use a variety of mechanisms - some 
>more effective or more morally acceptable than others - to implement 
>per-user fairness.

Per-user fairness is a perfectly innocent goal. The political problem 
has been about who's in control. That doesn't make per-user fairness 
wrong. The ISP deciding what per-user fairness means has been the 
wrong part. As you say, some ISPs have done this broadly in their 
customer's interests (more so where there's the discipline of competition).

[Aside: I believe some anti-bloat code being proposed on this list 
uses exactly the same politically unacceptable DPI techniques to 
detect exceptions to FQ, (e.g. for LEDBAT). Having to make exceptions 
to FQ should ring alarm bells that FQ isn't actually a good starting 
point. But people get confused and think that FQ holds the moral high 
ground, perhaps because it has inappropriately hijacked the word 
'fair' in its name.]


>But there is currently no easy way for the latter to communicate 
>with the former - ECN doesn't count here - if the former is 
>implemented at the CPE, thereby reducing their effectiveness.  Heck, 
>I have to manually configure my "router" (actually a computer) to 
>know what the upload bandwidth of the modem is.
>
>Why doesn't ECN count?  Because the signalled packets come through 
>the wrong channel - flowing past the router and passing through a 
>different queue, facing in the opposite direction.  The queue that 
>needs to see the information, doesn't.  In any case, if ECN were 
>already deployed sufficiently well, the sending host would be 
>backing off appropriately and we wouldn't be talking about the problem here.

We invented ConEx (congestion exposure) precisely to solve this 
problem of the signals being in the wrong direction.
<http://tools.ietf.org/html/draft-ietf-conex-abstract-mech>

Cheers


Bob


>  - Jonathan Morton

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design