General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Bob Briscoe <bob.briscoe@bt.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] What is fairness, anyway? was: Re: finally...  winning on wired!
Date: Fri, 6 Jan 2012 22:34:06 +0200	[thread overview]
Message-ID: <E0087F58-3294-436A-9F36-29543DC8F2B4@gmail.com> (raw)
In-Reply-To: <201201051753.q05Hqx78012678@bagheera.jungle.bt.co.uk>


On 5 Jan, 2012, at 7:52 pm, Bob Briscoe wrote:

>> > 1: the 'slower flows gain priority' question is my gravest concern
>> > (eg, ledbat, bittorrent). It's fixable with per-host FQ.
>> 
>> Meaning that you don't want to hand priority to stuff that is intended
>> to stay in the background?
> 
> 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*.

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

> 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?

We do need both per-flow and per-user fairness.  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.

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.

 - Jonathan Morton


  parent reply	other threads:[~2012-01-06 20:34 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-02  0:40 [Bloat] " Dave Taht
2012-01-02  5:22 ` Eric Dumazet
2012-01-02  8:07   ` Dave Taht
2012-01-02 21:31     ` Dave Taht
2012-01-02 22:14       ` Albert Rafetseder
2012-01-02 22:33         ` Dave Taht
2012-01-04 15:25       ` [Bloat] What is fairness, anyway? was: " Jim Gettys
2012-01-04 16:16         ` Dave Taht
2012-01-04 17:23           ` Jim Gettys
2012-01-04 17:36           ` Justin McCann
2012-01-04 17:40             ` Eric Dumazet
     [not found]             ` <CAFkTFa89mOmbcOV1PWX3my04rK4NsEvyakcQV2j54qa0gzAViQ@mail.g mail.com>
2012-01-05 17:52               ` Bob Briscoe
2012-01-06 17:42                 ` Jim Gettys
2012-01-06 18:09                   ` Dave Taht
2012-01-06 19:57                   ` Eric Dumazet
2012-01-06 20:34                 ` Jonathan Morton [this message]
2012-01-07 19:42                   ` Bob Briscoe
2012-01-07 22:16                     ` Wesley Eddy
2012-01-08  0:40                 ` Dave Taht
     [not found]                   ` <CAA93jw7xKwdUeT7wFNoiM8RQp1--==Eazdo0ucc44vz+L1U06g@mail.g mail.com>
2012-01-09  5:38                     ` Bob Briscoe
2012-01-11  7:26                       ` Dave Taht
     [not found]                         ` <CAA93jw4KJdYwrAuk7-yHDYCGBh1s6mE47eAYu2_LRfY45-qZ2g@mail.g mail.com>
2012-01-14 11:06                           ` Bob Briscoe
2012-01-13 21:45                   ` Dan Siemon
2012-01-14 15:55                     ` Dave Taht
2012-01-04 16:22         ` Eric Dumazet
2012-02-05  0:24         ` George B.
2012-02-05  0:43           ` Jonathan Morton
2012-02-05  1:57             ` George B.
2012-02-05  2:05               ` john thompson
2012-02-05  7:39             ` Eric Dumazet
     [not found]               ` <CAA93jw68yntHkhETQ1a9-Azu7UXEuU9f5fgOsB25hvA240iApg@mail.gmail.com>
2012-02-05 14:24                 ` Dave Taht
2012-02-05 17:53               ` Justin McCann
2012-02-05 18:21                 ` Eric Dumazet
2012-01-14 16:35 Jesper Dangaard Brouer
2012-01-15  9:49 ` Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E0087F58-3294-436A-9F36-29543DC8F2B4@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=bob.briscoe@bt.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox