From: dpreed@reed.com
To: "Jonathan Morton" <chromatix99@gmail.com>
Cc: "Maciej Soltysiak" <maciej@soltysiak.com>,
"cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next
Date: Sat, 17 Sep 2016 17:11:32 -0400 (EDT) [thread overview]
Message-ID: <1474146692.035424358@mobile.rackspace.com> (raw)
The assumption that each flow on a path has a minimum, stable RTT fails in wireless and multi path networks.
However, it's worth remembering two things: buffering above a certain level is never an improvement, and flows through any shared router come and go quite frequently on the real Internet.
Thus RTT on a single flow is not a reasonable measure of congestion. ECN marking is far better and packet drops are required for bounding time to recover after congestion failure.
The authors suffer from typical naivete by thinking all flows are for file transfer and that file transfer throughput is the right basic perspective, rather than end to end latency/jitter due to sharing, and fair sharing stability.
-----Original Message-----
From: "Jonathan Morton" <chromatix99@gmail.com>
Sent: Sat, Sep 17, 2016 at 4:11 pm
To: "Maciej Soltysiak" <maciej@soltysiak.com>
Cc: "Maciej Soltysiak" <maciej@soltysiak.com>, "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next
> On 17 Sep, 2016, at 21:34, Maciej Soltysiak wrote:
>
> Cake and fq_codel work on all packets and aim to signal packet loss early to network stacks by dropping; BBR works on TCP and aims to prevent packet loss.
By dropping, *or* by ECN marking. The latter avoids packet loss.
- Jonathan Morton
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
next reply other threads:[~2016-09-17 21:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-17 21:11 dpreed [this message]
2016-09-17 21:33 ` Dave Taht
2016-09-19 20:26 ` Dave Taht
2016-09-20 20:27 ` dpreed
2016-09-21 6:24 ` Mikael Abrahamsson
2016-09-21 16:57 ` dpreed
2016-09-21 7:32 ` Alan Jenkins
2016-09-21 17:04 ` dpreed
2016-09-21 18:00 ` Mikael Abrahamsson
2016-09-21 21:13 ` dpreed
2016-09-21 18:42 ` Alan Jenkins
2016-09-21 21:10 ` dpreed
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/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1474146692.035424358@mobile.rackspace.com \
--to=dpreed@reed.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=maciej@soltysiak.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