From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D56233B29D for ; Mon, 5 Apr 2021 12:25:38 -0400 (EDT) Received: by mail-lj1-x22a.google.com with SMTP id c6so11767281lji.8 for ; Mon, 05 Apr 2021 09:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=edmison-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PuxxxpQ695EoQYrXmTKsECvbGAPQ1AgozHrYygxRROU=; b=qhlW1hx6qoCeW5gEwBVDxiTJFxxUDRj3ShDdNjWRApvh0BP/Z/W718zZKF4zAhLmXw fF8VDcr8T6GQXnKZesuz9QQBqQgGk94lQb3Bo1XuHinq1B+PU5OSh20WcaI0qgYfF0nH GU5qLCQ5hozq0ZS3dqXKgjigpKdbSaH2WVMpXe7kZQLOuwU8L/tVydc5Q4cwyDqrpqKx ia73Xc8aJc3Z3M9LWeuihE+IqhTvmlxdy+FX/vmkPGjjVCkowwdWjpilnPDRjz+9y3Nk OFsauZhr23O8aIQbIPkwSl90+QwnIsxi2EOR9Sy1Dq/FJ0NvxmOWI4ACgvVru2gsikej 9AnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PuxxxpQ695EoQYrXmTKsECvbGAPQ1AgozHrYygxRROU=; b=Y6lu6seTELpDfwBimo6Q/ThL50m+3bczyrpMorbHyj4HACbXGKDlCDw4cKrmzEIyTt F4i896Q/adwwhhsUpVQ4e6uNJYFuSLHnzIw8JxNcX1hM8uDsRibeCx6nVjNxlnZFzxgx Pc83nbUkHir6YZVl1dWkBjIxJz4DLLiHKIZHH8GGdcgeImCzyjhrngDqfO/OiWoAiCKr LvrCKIjcHgs2cbe5f1mW78yrgq1k/DOlPZAKFVSNF2XDYId9H7RAEk9Y6AFugVN4fuUW dhJo2HE6VRC3NBot1ue5RPvSjNyqk5e3KtZDKf9yJRdwoM3sKLgRYLU8l9EzjA/Cvnyt pqUg== X-Gm-Message-State: AOAM533vA9uYKJNs5jBOh+V0WBE8segcZ0ZtyjqbxXW4+KRxM5Gvsy3U zU09kYl1v4boe8dTEgDJVD+x1I4Hjdtvj5ihhWFMiw== X-Google-Smtp-Source: ABdhPJx847H9svBVutnsqc57jOsIuNn7rWrKSEjblIb2UmoTK/xD9AmHoWvCSzuT0wo78MR7zyhe4ooOkGWcl8f3KVU= X-Received: by 2002:a2e:b5b9:: with SMTP id f25mr16861535ljn.90.1617639937631; Mon, 05 Apr 2021 09:25:37 -0700 (PDT) MIME-Version: 1.0 References: <9A233C8C-5C48-4483-A087-AA5FE1011388@gmail.com> <20210405081355.14f10a08@hermes.local> In-Reply-To: From: Kelvin Edmison Date: Mon, 5 Apr 2021 12:25:26 -0400 Message-ID: To: David Lang Cc: Stephen Hemminger , Rich Brown , bloat Content-Type: multipart/alternative; boundary="000000000000db7ab105bf3c2536" Subject: Re: [Bloat] Questions for Bufferbloat Wikipedia article X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2021 16:25:39 -0000 --000000000000db7ab105bf3c2536 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > On Mon, 5 Apr 2021, Stephen Hemminger wrote: > > > On Mon, 5 Apr 2021 08:46:15 -0400 > > Rich Brown wrote: > > > >> Dave T=C3=A4ht has put me up to revising the current Bufferbloat artic= le 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 Dar= k > 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 Dat= a > Center. Is it worth having the Wikipedia article distinguish between Data > Center equipment and CPE/home/last mile equipment? Similarly, is the "blo= at > 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 thum= b" > 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 mak= e > contact with some of the reviewers and editors who've been maintaining th= e > page to establish some bona fides and rapport... > >> > >> Many thanks! > >> > >> Rich > > > > I like to think of Bufferbloat as a combination of large buffers and ho= w > 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 > --000000000000db7ab105bf3c2536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've been lurking on the bufferbloat mailing list for = a while now, without volunteering in the same fashion as the core contribut= ors.=C2=A0 But I do have some thoughts as someone who is not quite at the l= evel of writing kernel drivers; maybe this is helpful when updating the def= inition.

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 alre= ady, and draw them in to the next level of detail.

To that end, I would propose the following for discussion:
Buffe= rbloat is the difference in latency for a connection when it is lightly=C2= =A0loaded vs when it is fully loaded. =C2=A0(Here, i am trying to provide t= erms that are somewhat clear and simple to an average user, that will conne= ct them to things they do already i.e. fully use their=C2=A0internet connec= tion 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 compet= ing users with different priorities (gaming vs. uploading documents or pres= entations).

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

I hope this is useful,
=C2=A0 Kelvin

On Mo= n, 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=C3=A4ht has put me up to revising the current Bufferbloat a= rticle on Wikipedia (https://en.wikipedia.org/wiki/Bufferbl= oat)
>>
>> 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 si= te, "Bufferbloat is the undesirable latency that comes from a router o= r other network equipment buffering too much data." (This suggests buf= ferbloat 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/d= ocument/5755608), "Bufferbloat is the existence of excessively lar= ge (bloated) buffers in systems, particularly network communication systems= ." (This suggests bufferbloat is an unfortunate state of nature, measu= red in units of "unhappiness" :-)
>>
>> c) Or some other definition?
>>
>> 2) All network equipment can be bloated. I have seen (but not real= ly followed) controversy regarding the amount of buffering needed in the Da= ta Center. Is it worth having the Wikipedia article distinguish between Dat= a Center equipment and CPE/home/last mile equipment? Similarly, is the &quo= t;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 shoul= d accommodate buffering 250 msec of traffic(!) Is this a real "rule of= thumb" or just an often-repeated but unscientific suggestion? Can som= eone give pointers to best practices?
>>
>> 4) Meta question: Can anyone offer any advice on making a wholesal= e change to a Wikipedia article? Before I offer a fork-lift replacement I w= ould a) solicit advice on the new text from this list, and b) try to make c= ontact with some of the reviewers and editors who've been maintaining t= he page to establish some bona fides and rapport...
>>
>> Many thanks!
>>
>> Rich
>
> I like to think of Bufferbloat as a combination of large buffers and h= ow algorithms react to those buffers.

I think there are two things

1. what bufferbloat is

=C2=A0 =C2=A0 bufferbloat is the result of memory getting cheaper faster th= an 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 i= nto
the buffer and when it gets transmitted)

So in a high bandwidth environment (like a datacenter) you can use much lar= ger
buffers than when you are on a low bandwidth line

David Lang_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
--000000000000db7ab105bf3c2536--