General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Kelvin Edmison <kelvin@edmison.net>
To: David Lang <david@lang.hm>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	Rich Brown <richb.hanover@gmail.com>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Questions for Bufferbloat Wikipedia article
Date: Mon, 5 Apr 2021 12:25:26 -0400	[thread overview]
Message-ID: <CALErE73gyn4DfgZW4ifJrVZJ31ciRaXxqrWS-mApwN=4DTs2pg@mail.gmail.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2104050815220.18176@qynat-yncgbc>

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

I've been lurking on the bufferbloat mailing list for a while now, without
volunteering in the same fashion as the core contributors.  But I do have
some thoughts as someone who is not quite at the level of writing kernel
drivers; maybe this is helpful when updating the definition.

I think we need to define what it is (in terms of user-perceivable
experience) before we get to the causes and why it's a problem.
In essence, link it to what average people know already, and draw them in
to the next level of detail.

To that end, I would propose the following for discussion:
Bufferbloat is the difference in latency for a connection when it is
lightly loaded vs when it is fully loaded.  (Here, i am trying to provide
terms that are somewhat clear and simple to an average user, that will
connect them to things they do already i.e. fully use their internet
connection for an upload or download.)

Then, I think it is useful to move into some examples of how it can be
perceived (audio call stutter, video call stutter) especially in the
presence of multiple competing users with different priorities (gaming vs.
uploading documents or presentations).

And then we can dig into the causes (e.g. over-provisioned buffers, poor
inter-flow management, etc), means of explicitly measuring it, approaches
for mitigating or fixing it, etc.

I hope this is useful,
  Kelvin

On Mon, Apr 5, 2021 at 11:24 AM David Lang <david@lang.hm> wrote:

> On Mon, 5 Apr 2021, Stephen Hemminger wrote:
>
> > On Mon, 5 Apr 2021 08:46:15 -0400
> > Rich Brown <richb.hanover@gmail.com> wrote:
> >
> >> Dave Täht has put me up to revising the current Bufferbloat article on
> Wikipedia (https://en.wikipedia.org/wiki/Bufferbloat)
> >>
> >> Before I get into it, I want to ask real experts for some guidance...
> Here goes:
> >>
> >> 1) What is *our* definition of Bufferbloat? (We invented the term, so I
> think we get to define it.)
> >>
> >> a) Are we content with the definition from the bufferbloat.net site,
> "Bufferbloat is the undesirable latency that comes from a router or other
> network equipment buffering too much data." (This suggests bufferbloat is
> latency, and could be measured in seconds/msec.)
> >>
> >> b) Or should we use something like Jim Gettys' definition from the Dark
> Buffers article (https://ieeexplore.ieee.org/document/5755608),
> "Bufferbloat is the existence of excessively large (bloated) buffers in
> systems, particularly network communication systems." (This suggests
> bufferbloat is an unfortunate state of nature, measured in units of
> "unhappiness" :-)
> >>
> >> c) Or some other definition?
> >>
> >> 2) All network equipment can be bloated. I have seen (but not really
> followed) controversy regarding the amount of buffering needed in the Data
> Center. Is it worth having the Wikipedia article distinguish between Data
> Center equipment and CPE/home/last mile equipment? Similarly, is the "bloat
> condition" and its mitigation qualitatively different between those
> applications? Finally, do any of us know how frequently data
> centers/backbone ISPs experience buffer-induced latencies? What's the
> magnitude of the impact?
> >>
> >> 3) The Wikipedia article mentions guidance that network gear should
> accommodate buffering 250 msec of traffic(!) Is this a real "rule of thumb"
> or just an often-repeated but unscientific suggestion? Can someone give
> pointers to best practices?
> >>
> >> 4) Meta question: Can anyone offer any advice on making a wholesale
> change to a Wikipedia article? Before I offer a fork-lift replacement I
> would a) solicit advice on the new text from this list, and b) try to make
> contact with some of the reviewers and editors who've been maintaining the
> page to establish some bona fides and rapport...
> >>
> >> Many thanks!
> >>
> >> Rich
> >
> > I like to think of Bufferbloat as a combination of large buffers and how
> algorithms react to those buffers.
>
> I think there are two things
>
> 1. what bufferbloat is
>
>     bufferbloat is the result of memory getting cheaper faster than
> bandwidth
> increased, combined with throughput benchmarking that drastically
> penalized
> end-to-end retries.
>
> I think this definition is pretty academic and not something to worry
> about
> using.
>
> 2. why it's a problem
>
> the problems show up when the buffer represents too much time worth of
> data to
> transmit (the time between when the last byte in the buffer gets inserted
> into
> the buffer and when it gets transmitted)
>
> So in a high bandwidth environment (like a datacenter) you can use much
> larger
> buffers than when you are on a low bandwidth line
>
> David Lang_______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

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

  parent reply	other threads:[~2021-04-05 16:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-05 12:46 Rich Brown
2021-04-05 15:13 ` Stephen Hemminger
2021-04-05 15:24   ` David Lang
2021-04-05 15:57     ` Dave Collier-Brown
2021-04-05 16:25     ` Kelvin Edmison [this message]
2021-04-05 18:00 ` [Bloat] Questions for Bufferbloat Wikipedia article - question #2 Rich Brown
2021-04-05 18:08   ` David Lang
2021-04-05 20:30     ` Erik Auerswald
2021-04-05 20:36       ` Dave Taht
2021-04-05 21:49 ` [Bloat] Questions for Bufferbloat Wikipedia article Sebastian Moeller
2021-04-05 21:55   ` Dave Taht
2021-04-06  0:47   ` Erik Auerswald
2021-04-06  6:31     ` Sebastian Moeller
2021-04-06 18:50       ` Erik Auerswald
2021-04-06 20:02         ` Bless, Roland (TM)
2021-04-06 21:59           ` Erik Auerswald
2021-04-06 23:32             ` Stephen Hemminger
2021-04-06 23:54               ` David Lang
2021-04-07 11:06             ` Bless, Roland (TM)
2021-04-27  1:41               ` Dave Taht
2021-04-27  7:25                 ` Bless, Roland (TM)
2021-04-06 20:01       ` Bless, Roland (TM)
2021-04-06 21:30         ` Sebastian Moeller
2021-04-06 21:36           ` Jonathan Morton
2021-04-07 10:39           ` Bless, Roland (TM)
2021-04-06 18:54 ` Neil Davies

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='CALErE73gyn4DfgZW4ifJrVZJ31ciRaXxqrWS-mApwN=4DTs2pg@mail.gmail.com' \
    --to=kelvin@edmison.net \
    --cc=bloat@lists.bufferbloat.net \
    --cc=david@lang.hm \
    --cc=richb.hanover@gmail.com \
    --cc=stephen@networkplumber.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