From: Jonathan Morton <chromatix99@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] updating the theory of buffer sizing
Date: Mon, 11 Oct 2021 09:10:47 +0300 [thread overview]
Message-ID: <D0A206EC-BE44-4B7C-A0E6-1256EB70640C@gmail.com> (raw)
In-Reply-To: <CAA93jw664Tq25z0-dNt9vpr34Gc0-mB04W8F2bdi2WtfvrHa1g@mail.gmail.com>
> On 10 Oct, 2021, at 8:48 pm, Dave Taht <dave.taht@gmail.com> wrote:
>
> This latest from Nick & co, was quite good:
>
> https://arxiv.org/pdf/2109.11693.pdf
Skip the false modesty - I think this is very important work, actually. I would expect it to get cited a heck of a lot in future work, both in academia and in the IETF.
In terms of its content, it confirms, contextualises, and formalises various things that I already understood at an intuitive level. The mathematics involved is simple and accessible (unlike some papers I've read recently), and the practical explanations of the observed behaviours are clear and to the point. I particularly appreciate the way they were able to parameterise certain characteristics on a continuum, rather than all-or-nothing, as that captures the complex characteristics of real traffic much better.
The observations about synchronisation of congestion responses are also very helpful. When synchronised, the aggregate behaviour of many flows is similar to that of a much smaller number, perhaps even a single flow. When desynchronised, the well-known statistical multiplexing effects apply. They also clearly explain why the "hard threshold" type of ECN marking is undesirable - because it provokes synchronisation in a way that tail-drop does not (and this is also firmly related to a point we discussed last week).
Notably, they started seeing the effects of burstiness, on a small and theoretically "smooth" network, on timescales of approximately a seventh of a millisecond (20 packets, 9000 byte MTU, 10Gbps). They were unable to reduce buffer sizes below that level without throughput dropping well below their theoretical predictions, which had held true down to that point. This has implications for setting AQM targets and tolerances in even near-ideal network environments. But they did also note that BBR showed much less sensitivity to this effect, as it uses pacing. In any case, it confirms that the first role of a buffer is to absorb bursts without excessive loss.
- Jonathan Morton
prev parent reply other threads:[~2021-10-11 6:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-10 17:48 Dave Taht
2021-10-11 6:10 ` Jonathan Morton [this message]
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=D0A206EC-BE44-4B7C-A0E6-1256EB70640C@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=dave.taht@gmail.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