From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by huchra.bufferbloat.net (Postfix) with ESMTP id C81E62013F8 for ; Sat, 7 Jan 2012 11:44:13 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 Jan 2012 19:44:11 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 Jan 2012 19:44:11 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1325965449821; Sat, 7 Jan 2012 19:44:09 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.80.40]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q07Ji3Xu021105; Sat, 7 Jan 2012 19:44:04 GMT Message-Id: <201201071944.q07Ji3Xu021105@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 07 Jan 2012 19:42:51 +0000 To: Jonathan Morton From: Bob Briscoe In-Reply-To: References: <1325481751.2526.23.camel@edumazet-laptop> <4F046F7B.6030905@freedesktop.org> <201201051753.q05Hqx78012678@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 07 Jan 2012 19:44:11.0133 (UTC) FILETIME=[BA3C82D0:01CCCD74] Cc: bloat Subject: Re: [Bloat] What is fairness, anyway? was: Re: finally... winning on wired! X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 19:44:14 -0000 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" 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. Cheers Bob > - Jonathan Morton ________________________________________________________________ Bob Briscoe, BT Innovate & Design