From: Daniel Sterling <sterling.daniel@gmail.com>
To: Luca Muscariello <muscariello@ieee.org>
Cc: Dave Taht <dave.taht@gmail.com>,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
Carlo Augusto Grazia <carloaugusto.grazia@unimore.it>,
jamshid@whatsapp.com, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] [Make-wifi-fast] the future belongs to pacing
Date: Mon, 6 Jul 2020 10:14:46 -0400 [thread overview]
Message-ID: <CAJZMiueC9JdLUx1Py-wiZHnveWScB+GEBN9P7ie70HC=M2i1Aw@mail.gmail.com> (raw)
In-Reply-To: <CAH8sseR_WtcWj=UkcJnB+J5vAeFZ0sLfTcOMwFW2rha-AucXpg@mail.gmail.com>
On Mon, Jul 6, 2020 at 10:09 AM Luca Muscariello <muscariello@ieee.org> wrote:
> If BBR can fix that by having a unique model for all these cases that would make deprecation, as intended in the paper,
> likely to happen.
Interesting! Thank you all for helping a layperson like me understand.
Obviously getting CC / latency control "correct" under wifi is a
difficult problem.
I am wondering if you (the experts) have confidence we can solve it --
that is, can end-users eventually see low latency by default with
standard gear?
Or are shared transmission mediums like wifi doomed to require large
buffers for throughput, which means low latency can't be something we
can have "out of the box" -- ? Is sacrificing throughput for latency
required for "always low" latency on wifi?
Thanks,
Dan
next prev parent reply other threads:[~2020-07-06 14:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAA93jw5RuBfDA=Yku6+Rm+YEdrUzvZMsoAwVXYduZjBmMVf43Q@mail.gmail.com>
[not found] ` <CALDN43m=2SzkT4vLeqiFxE6PRd+ZKR1hdeMRwtqbTFuAL7nMLA@mail.gmail.com>
2019-12-13 21:25 ` [Bloat] " Dave Taht
2020-07-04 17:29 ` Matt Mathis
2020-07-06 14:08 ` [Bloat] [Make-wifi-fast] " Luca Muscariello
2020-07-06 14:14 ` Daniel Sterling [this message]
2020-07-06 17:01 ` Toke Høiland-Jørgensen
[not found] ` <mailman.763.1593883755.24343.bloat@lists.bufferbloat.net>
2020-07-04 17:52 ` [Bloat] " Daniel Sterling
2020-07-04 18:02 ` Jonathan Morton
2020-07-04 18:29 ` Sebastian Moeller
2020-07-05 6:10 ` Matt Mathis
2020-07-05 12:01 ` Sebastian Moeller
2020-07-05 17:07 ` Matt Mathis
2020-07-05 17:29 ` 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 18:32 ` Roland Bless
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='CAJZMiueC9JdLUx1Py-wiZHnveWScB+GEBN9P7ie70HC=M2i1Aw@mail.gmail.com' \
--to=sterling.daniel@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=carloaugusto.grazia@unimore.it \
--cc=dave.taht@gmail.com \
--cc=jamshid@whatsapp.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=muscariello@ieee.org \
/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