From: Jonathan Morton <chromatix99@gmail.com>
To: Daniel Sterling <sterling.daniel@gmail.com>
Cc: Matt Mathis <mattmathis@google.com>,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
Carlo Augusto Grazia <carloaugusto.grazia@unimore.it>,
bloat <bloat@lists.bufferbloat.net>,
jamshid@whatsapp.com
Subject: Re: [Make-wifi-fast] [Bloat] the future belongs to pacing
Date: Sat, 4 Jul 2020 21:02:26 +0300 [thread overview]
Message-ID: <26B050EB-25D5-4545-B6A6-5265ED146617@gmail.com> (raw)
In-Reply-To: <CAJZMiueLmy82f=k6LJChwECcs+KK-kKAxm+srZBSRymTWRiMcw@mail.gmail.com>
> On 4 Jul, 2020, at 8:52 pm, Daniel Sterling <sterling.daniel@gmail.com> wrote:
>
> could someone explain this to a lay person or point to a doc talking
> about this more?
>
> What does BBR do that's different from other algorithms? Why does it
> break the clock? Before BBR, was the clock the only way TCP did CC?
Put simply, BBR directly probes for the capacity and baseline latency of the path, and picks a send rate (implemented using pacing) and a failsafe cwnd to match that. The bandwidth probe looks at the rate of returning acks, so in fact it's still using the ack-clock mechanism, it's just connected much less directly to the send rate than before.
Other TCPs can use pacing as well. In that case the cwnd and RTT estimate are calculated in the normal way, and the send rate (for pacing) is calculated from those. It prevents a sudden opening of the receive or congestion windows from causing a huge burst which would tend to swamp buffers.
- Jonathan Morton
next prev parent reply other threads:[~2020-07-04 18:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-13 19:53 [Make-wifi-fast] IEEE 802.11n/ac Wireless Network Efficiency under different TCP Congestion Controls Dave Taht
2019-12-13 21:05 ` Carlo Augusto Grazia
2019-12-13 21:25 ` [Make-wifi-fast] the future belongs to pacing Dave Taht
2020-07-04 17:29 ` [Bloat] " Matt Mathis
[not found] ` <mailman.763.1593883755.24343.bloat@lists.bufferbloat.net>
2020-07-04 17:52 ` [Make-wifi-fast] " Daniel Sterling
2020-07-04 18:02 ` Jonathan Morton [this message]
2020-07-04 18:29 ` Sebastian Moeller
2020-07-05 6:10 ` Matt Mathis
2020-07-05 12:01 ` [Make-wifi-fast] " Sebastian Moeller
2020-07-05 17:07 ` Matt Mathis
2020-07-05 17:29 ` [Make-wifi-fast] " Sebastian Moeller
2020-07-05 17:43 ` Michael Richardson
2020-07-05 18:09 ` Stephen Hemminger
2020-07-05 18:13 ` Jonathan Morton
2020-07-05 23:06 ` Matt Mathis
2020-07-06 14:08 ` [Make-wifi-fast] " Luca Muscariello
2020-07-06 14:14 ` [Make-wifi-fast] [Bloat] " Daniel Sterling
2020-07-06 17:01 ` Toke Høiland-Jørgensen
2019-12-13 21:09 ` [Make-wifi-fast] IEEE 802.11n/ac Wireless Network Efficiency under different TCP Congestion Controls Holland, Jake
2019-12-13 21:18 ` Carlo Augusto Grazia
2019-12-13 23:06 ` 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/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26B050EB-25D5-4545-B6A6-5265ED146617@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=carloaugusto.grazia@unimore.it \
--cc=jamshid@whatsapp.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=mattmathis@google.com \
--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