General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Michael Welzl <michawe@ifi.uio.no>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: bloat <bloat@lists.bufferbloat.net>,
	Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
Subject: Re: [Bloat] AQM and PPP on Linux
Date: Tue, 28 Jul 2015 19:11:34 +0200	[thread overview]
Message-ID: <052B5B2C-E784-4B48-8447-6EDCCB987CB4@ifi.uio.no> (raw)
In-Reply-To: <F41B146A-E9FD-4C32-8C0D-48B5FD2148B6@gmx.de>


> On 28. jul. 2015, at 18.22, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> Hi Simon,
> 
> On Jul 28, 2015, at 16:31 , Simon Barber <simon@superduper.net> wrote:
> 
>> The issue is that Codel tries to keep the delay low, and will start dropping when sojourn time grows above 5ms for 100ms. For longer RTT links more delay is necessary to avoid underutilizing the link. This is due to the multiplicative decrease - it's worst with Reno, where the halving of cWind means that you need to have a full BDP of data in the buffer to avoid the link going idle when cWind is halved. With longer RTTs this means more delay than Codel allows is required to avoid a throughput hit. The worst case happens when a single flow is controlled, but that can be a common situation. My proposal is to sense and have the target value in Codel automatically adjust when this worst case scenario happens - which would mitigate most of the downside.
> 
> 	According to theory you should adapt interval if at all and the set target between 5-10% of that interval. See https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/?include_text=1 sections 4.3 and 4.4. Now that could all be off.The upshot is increasing target as a response for long RTTs will sacrifice latency again for bandwidth, pretty much that the avoidance of is codel’s claim to fame ;)

The only way to fix this trade-off is to change TCP, to back off less *only when the queue was small*. We tried what we think is the simplest possible way to do this: only a sender-side change, using ECN as an indication that there is an AQM mechanism on the path, not a long queue (and hence backing off by less is ok). It works pretty well. See:
http://caia.swin.edu.au/reports/150710A/CAIA-TR-150710A.pdf
(a few of the graphs are simulations, but many were from real-life tests - appendix B says which).

...and the draft, which was presented to TCPM at the Prague IETF last week:
https://tools.ietf.org/html/draft-khademi-alternativebackoff-ecn

Cheers,
Michael


  reply	other threads:[~2015-07-28 17:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-28 13:09 Juliusz Chroboczek
2015-07-28 13:33 ` Toke Høiland-Jørgensen
2015-07-28 13:50   ` Juliusz Chroboczek
2015-07-28 14:05     ` Toke Høiland-Jørgensen
2015-07-28 14:11       ` Simon Barber
2015-07-28 14:21         ` Eric Dumazet
2015-07-28 14:31           ` Simon Barber
2015-07-28 14:43             ` Jonathan Morton
2015-07-28 14:49             ` Eric Dumazet
2015-07-28 14:55               ` Eric Dumazet
2015-07-28 16:02               ` Alan Jenkins
2015-07-28 16:22             ` Sebastian Moeller
2015-07-28 17:11               ` Michael Welzl [this message]
2015-07-29  7:19         ` David Lang
2015-07-28 19:20       ` Juliusz Chroboczek
2015-07-28 19:29         ` Alan Jenkins
2015-07-28 14:18     ` Eric Dumazet
2015-07-28 14:44 ` Dave Taht
2015-07-28 14:52   ` Eric Dumazet
2015-07-28 19:24   ` Juliusz Chroboczek
2015-07-28 19:31     ` Bill Ver Steeg (versteb)
2015-07-28 20:10     ` Alan Jenkins
2015-07-28 20:45       ` Alan Jenkins
2015-07-29 13:15   ` Stefan Alfredsson
2015-07-29 13:41     ` 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=052B5B2C-E784-4B48-8447-6EDCCB987CB4@ifi.uio.no \
    --to=michawe@ifi.uio.no \
    --cc=bloat@lists.bufferbloat.net \
    --cc=jch@pps.univ-paris-diderot.fr \
    --cc=moeller0@gmx.de \
    /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