From: dpreed@reed.com
To: "Mikael Abrahamsson" <swmike@swm.pp.se>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Ubiquiti QOS
Date: Mon, 26 May 2014 10:01:19 -0400 (EDT) [thread overview]
Message-ID: <1401112879.32226492@apps.rackspace.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1405261454070.29282@uplift.swm.pp.se>
[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]
On Monday, May 26, 2014 9:02am, "Mikael Abrahamsson" <swmike@swm.pp.se> said:
> So, I'd agree that a lot of the time you need very little buffers, but
> stating you need a buffer of 2 packets deep regardless of speed, well, I
> don't see how that would work.
>
My main point is that looking to increased buffering to achieve throughput while maintaining latency is not that helpful, and often causes more harm than good. There are alternatives to buffering that can be managed more dynamically (managing bunching and something I didn't mention - spreading flows or packets within flows across multiple routes when a bottleneck appears - are some of them).
I would look to queue minimization rather than "queue management" (which implied queues are often long) as a goal, and think harder about the end-to-end problem of minimizing total end-to-end queueing delay while maximizing throughput.
It's clearly a totally false tradeoff between throughput and latency - in the IP framework. There is no such tradeoff for the operating point. There may be such a tradeoff for certain specific implementations of TCP, but that's not fixed in stone.
[-- Attachment #2: Type: text/html, Size: 1666 bytes --]
next prev parent reply other threads:[~2014-05-26 14:01 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-25 6:17 Dane Medic
2014-05-25 14:23 ` Valdis.Kletnieks
2014-05-25 15:42 ` Mikael Abrahamsson
2014-05-25 20:00 ` dpreed
2014-05-26 0:18 ` Mikael Abrahamsson
2014-05-26 4:49 ` dpreed
2014-05-26 13:02 ` Mikael Abrahamsson
2014-05-26 14:01 ` dpreed [this message]
2014-05-26 14:11 ` Mikael Abrahamsson
2014-05-26 15:31 ` David P. Reed
2014-05-27 21:19 ` David Lang
2014-05-27 22:00 ` Dave Taht
2014-05-27 23:27 ` David Lang
2014-05-28 2:12 ` Dave Taht
2014-05-28 3:21 ` David Lang
2014-05-28 15:52 ` dpreed
2014-05-28 16:34 ` David Lang
2014-05-27 15:23 ` Jim Gettys
2014-05-27 17:31 ` Dave Taht
2014-05-28 15:33 ` dpreed
2014-05-28 15:20 ` dpreed
2014-05-28 18:33 ` David Lang
2014-05-29 12:11 ` David P. Reed
2014-05-29 15:29 ` dpreed
2014-05-29 19:30 ` David Lang
2014-05-29 23:40 ` Michael Richardson
2014-05-30 0:32 ` David P. Reed
2014-05-30 0:36 ` Dave Taht
2014-05-25 18:39 ` Sebastian Moeller
2014-05-25 19:33 ` 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/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=1401112879.32226492@apps.rackspace.com \
--to=dpreed@reed.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=swmike@swm.pp.se \
/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