From: Jonathan Morton <chromatix99@gmail.com>
To: Daniel Sterling <sterling.daniel@gmail.com>
Cc: "Stephen Hemminger" <stephen@networkplumber.org>,
"Jonathan Morton via Bloat" <bloat@lists.bufferbloat.net>,
"Bjørn Ivar Teigen" <bjorn@domos.no>
Subject: Re: [Bloat] Researchers discover major roadblock in alleviating network congestion
Date: Sun, 7 Aug 2022 17:10:18 +0300 [thread overview]
Message-ID: <3E1E9948-7C5B-4A0C-830C-FCB45E191587@gmail.com> (raw)
In-Reply-To: <CAJZMiuce845VnbNWsKiqS7XZgBC5KaptxnW+oOpuQPxWMhzWww@mail.gmail.com>
> On 5 Aug, 2022, at 2:46 am, Daniel Sterling <sterling.daniel@gmail.com> wrote:
>
> "Flow control power is non-decentralizable" is from -- 1981? So we've
> known for 40 years that TCP streams won't play nicely with each other
> unless you shape them at the slower endpoint-- am I understanding that
> correctly? But we keep trying anyway? :)
More precisely, what was stated in 1981 was:
The specific metric of "network power" (the ratio of throughput to delay, calculated for each flow and globally summed) cannot reliably be maximised solely by the action of individual endpoints, without information from within the network itself.
Current TCPs generally converge not to maximise or even equalise "network power", but to equalise between flows a completely different metric called "RTT fairness", the *product* of throughput and delay. Adding information from the network via AQMs allows for reductions in delay with little effect on throughput, and thus a general increase in network power, but the theoretical global optimum is still not even approached.
Adding FQ in the network, thus implementing "max-min fairness" instead of "RTT fairness", hence equalising throughput instead of the product of throughput and delay. This is essentially the geometric mean of RTT-fairness and network power.
I believe it is actually possible to achieve equalisation of network power between flows, which would approach the global optimum of network power, using information from the network to guide endpoint behaviour. This is *only* possible using explicit information from the network, however, and is not directly compatible with the current congestion-control paradigm of RTT-fairness by default.
- Jonathan Morton
next prev parent reply other threads:[~2022-08-07 14:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-04 12:21 Bjørn Ivar Teigen
2022-08-04 21:45 ` Jonathan Morton
2022-08-04 23:24 ` Stephen Hemminger
2022-08-04 23:46 ` Daniel Sterling
2022-08-05 0:25 ` Dave Collier-Brown
2022-08-07 14:10 ` Jonathan Morton [this message]
2022-08-08 15:34 ` Michael Richardson
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=3E1E9948-7C5B-4A0C-830C-FCB45E191587@gmail.com \
--to=chromatix99@gmail.com \
--cc=bjorn@domos.no \
--cc=bloat@lists.bufferbloat.net \
--cc=stephen@networkplumber.org \
--cc=sterling.daniel@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