From: Neal Cardwell <ncardwell@google.com>
To: Rich Brown <richb.hanover@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.net>,
make-wifi-fast@lists.bufferbloat.net,
cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] [Cerowrt-devel] Comcast's NANOG slides re Bufferbloat posted (Oct 2016)
Date: Thu, 20 Oct 2016 14:44:39 -0000 [thread overview]
Message-ID: <CADVnQymkhvkS1eL5sjnzgKZ4QfXO8h2c-_Kmq=9mbgL1J1oCDg@mail.gmail.com> (raw)
In-Reply-To: <B706D9CB-DB33-4B12-AD01-DC2388607D86@gmail.com>
On Thu, Oct 20, 2016 at 8:15 AM, Rich Brown <richb.hanover@gmail.com> wrote:
>
> https://www.nanog.org/sites/default/files/20160922_Klatsky_First_Steps_In_v1.pdf
Regarding these passages from the slide deck:
What do the results suggest?
....
There may be a tradeoff between upload latency
and upload throughput, and that tradeoff is
not necessarily linear: there may be a “sweet spot”
where latency is noticeably reduced, while the
impact on throughput is negligible
What happens next?
....
Fixed buffer size setting impractical for scaled usage
I would agree that there is a delay/throughput "sweet spot", one that
varies across network scenarios. BBR congestion control is
specifically designed to dynamically estimate the bandwidth and delay
characteristics of the path, to estimate where that "sweet spot" is,
and operate near it.
The BBR paper ( currently on the ACM Queue site -
http://queue.acm.org/app/ ) has a diagram and discussion related to
this non-linear delay/throughput trade-off that the presentation
mentions.
neal
next prev parent reply other threads:[~2016-10-20 14:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-20 12:15 [Make-wifi-fast] " Rich Brown
2016-10-20 14:44 ` Neal Cardwell [this message]
2016-10-20 18:12 ` [Make-wifi-fast] [Cerowrt-devel] " Mikael Abrahamsson
2016-10-20 18:17 ` [Make-wifi-fast] [Bloat] " Klatsky, Carl
2016-10-20 21:41 ` Aaron Wood
2016-10-20 18:29 ` [Make-wifi-fast] " 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='CADVnQymkhvkS1eL5sjnzgKZ4QfXO8h2c-_Kmq=9mbgL1J1oCDg@mail.gmail.com' \
--to=ncardwell@google.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=richb.hanover@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