General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Luca Muscariello <muscariello@ieee.org>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] buffer sizing meeting notes
Date: Sat, 24 Aug 2019 11:15:57 +0200	[thread overview]
Message-ID: <CAH8sseTz=LC4YkAneh1Oy9aVDZBija-t5oUsvy3isoFa+K-Zeg@mail.gmail.com> (raw)
In-Reply-To: <36973E7C-0B93-4512-AB0B-917C807E9684@gmx.de>

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

On Sat, Aug 24, 2019 at 9:59 AM Sebastian Moeller <moeller0@gmx.de> wrote:

> Another nugget from the notes (
> http://yuba.stanford.edu/~bspang/buffer-sizing-meeting/notes/):
>
> This looks like an argument for fq_codel/cake's use of time instead of
> queue length, OR an argument for fq, because in a non-overwhelmed fq_system
> the local bucket's queue length should be somewhat stronger correlated with
> the sojurn times, than the sojurn time of a packet though a shared queue,
> no?
>

I believe that using fq there are good implications in terms of buffer
sizing rules.
The focus is only on backlogged flows. The sparse flow queue can be sized
purely based on queue load.
Which is trivial queuing theory formulas with non-TCP traffic.

For backlogged flows, sizing is just like sizing a buffer for a single TCP
flow. So the computation
can be done based on estimations of the number of backlogged flows and by
setting the cut-off BDP based on the
largest (maximum) min RTT one want to serve optimally.  So AQM is really
needed to get optimality.
The number of backlogged flows could be estimated as a max value or an avg
value, and this of course
changes depending on the network segment (DC, residential, campus, access,
backhaul etc.).

Nick McKeown has done quite a lot of research on the topic (reported in the
slide deck), so I find hilarious the following in his slide deck
"Personal confession: I have no idea what the general answer is" about
sizing buffers!

[-- Attachment #2: Type: text/html, Size: 2064 bytes --]

      reply	other threads:[~2019-08-24  9:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-23 16:07 Dave Taht
2019-08-23 17:13 ` Simon Barber
2019-08-23 17:24   ` Dave Taht
2019-08-24  7:54   ` Jesper Dangaard Brouer
2019-08-24  7:59     ` Sebastian Moeller
2019-08-24  9:15       ` Luca Muscariello [this message]

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='CAH8sseTz=LC4YkAneh1Oy9aVDZBija-t5oUsvy3isoFa+K-Zeg@mail.gmail.com' \
    --to=muscariello@ieee.org \
    --cc=bloat@lists.bufferbloat.net \
    --cc=brouer@redhat.com \
    --cc=moeller0@gmx.de \
    /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