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
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
