Re: [Bloat] Trying to *really* understand Linux pacing

Thanks, Michael, for the nice doc! This is really nice for the Linux networking community to have. I posted a few comments. thanks, neal ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

. > > > > On Apr 2, 2023, at 16:02, Neal Cardwell wrote: > > > > > > > > On Sun, Apr 2, 2023 at 8:14 AM Sebastian Moeller > wrote: > > Hi Ayush, > > > > > On Mar 28, 2023, at 11:36, Ayush Mishra via Bloat < > bloat@lists.bufferblo

Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

s > Sebastian > > > > Now that BBRv2 reacts to packet loss, are you making any of these > considerations too? > > > > This is not something I plan to present in iccrg tomorrow, just > something I was curious about :) > > > > Warmest regards, > >

Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

gree these are interesting topics. :-) best regards, neal > Warmest regards, > Ayush > > On Fri, Aug 26, 2022 at 9:36 PM 'Neal Cardwell' via BBR Development < > bbr-...@googlegroups.com> wrote: > >> Yes, I agree the assumptions are key here. One key aspect

Re: [Bloat] [bbr-dev] Aggregating without bloating - hard times for tcp and wifi

On Tue, Nov 22, 2022 at 2:43 PM 'Bob McMahon' via BBR Development < bbr-...@googlegroups.com> wrote: > Thanks for sharing this. Curious about how the xTSQ value can be set? Can > it be done with sysctl? > > *We continue our analysis by using the ms-version of TSQ patch, which > enables the tune

Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

n turn > can be used per Little's law > <https://en.wikipedia.org/wiki/Little%27s_law> to calculate effective > average queue depth, though this typically assumes a steady state > measurement. > > Bob > > On Sun, Aug 28, 2022 at 4:54 PM Neal Cardwell > wrote: > >&g

Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

, neal On Sun, Aug 28, 2022 at 6:39 PM Bob McMahon wrote: > Hi Neal, > > These look like steady-state bulk flow tests unless I'm missing something. > > Bob > > On Sun, Aug 28, 2022 at 11:43 AM Neal Cardwell > wrote: > >> Sure. For testing these kinds of prope

Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

McMahon wrote: > Curious to what you're doing during development, if you can share? > > Thanks, > Bob > > On Sat, Aug 27, 2022 at 7:44 AM Neal Cardwell > wrote: > >> Hi Bob, >> >> Good question. I can imagine a number of different techniques to

Re: [Bloat] [bbr-dev] Re: Are we heading towards a BBR-dominant Internet?

f-manpage.html>. We could pull the > size and period from a known distribution or distributions though not sure > what to pick. > > Thanks, > Bob > > Bob > > On Fri, Aug 26, 2022 at 6:36 AM 'Neal Cardwell' via BBR Development < > bbr-...@googlegroups.com>

Re: [Bloat] Are we heading towards a BBR-dominant Internet?

Yes, I agree the assumptions are key here. One key aspect of this paper is that it focuses on the steady-state behavior of bulk flows. Once you allow for short flows (like web pages, RPCs, etc) to dynamically enter and leave a bottleneck, the considerations become different. As is well-known,

Re: [Bloat] Of interest: Comcast AQM Paper

On Sat, Jul 31, 2021 at 3:27 PM Aaron Wood wrote: > > If we see that AQM appears to be not functioning as expected > for upstream connections on DOCSIS3.1, what's the right avenue > for getting that resolved? (and does that only apply to the > Comcast-owned, vs. customer-owned, modems?) FWIW,

Re: [Bloat] Abandoning Window-based CC Considered Harmful (was Re: Bechtolschiem)

On Thu, Jul 8, 2021 at 10:28 AM Bless, Roland (TM) wrote: > Hi Neal, > > On 08.07.21 at 15:29 Neal Cardwell wrote: > > On Thu, Jul 8, 2021 at 7:25 AM Bless, Roland (TM) > wrote: > >> It seems that in BBRv2 there are many more mechanisms present >> that try to co

Re: [Bloat] Abandoning Window-based CC Considered Harmful (was Re: Bechtolschiem)

On Thu, Jul 8, 2021 at 7:25 AM Bless, Roland (TM) wrote: > It seems that in BBRv2 there are many more mechanisms present > that try to control the amount of inflight data more tightly and the new > "cap" > is at 1.25 BDP. > To clarify, the BBRv2 cwnd cap is not 1.25*BDP. If there is no packet

Re: [Bloat] starlink bloat in review

On Sat, May 15, 2021 at 7:00 PM Matt Mathis via Bloat wrote: > > I don't understand: starlink doesn't terminate the TCP connection, > does it? Or are you referring to YT's BBR adequately addressing > Starlinks variable RTT? "Adequately" is probably the operative word. > It is not too hard to

Re: [Bloat] [bbr-dev] D* tcp looks pretty good, on paper

On Thu, Jan 7, 2021 at 1:35 PM Dave Taht wrote: > See: https://arxiv.org/pdf/2012.14996.pdf Thanks for the link! > > Things I really like: > > * they used flent > * Using "variance" as the principal signal. This is essentially one of > the great unpublished and unanalyzed improvements on the

Re: [Bloat] BBR implementations, knobs to turn?

A couple questions: - I guess this is Linux TCP BBRv1 ("bbr" module)? What's the OS distribution and exact kernel version ("uname -r")? - What do you mean when you say "The old server allows for more re-transmits"? - If BBRv1 is suffering throughput problems due to high retransmit rates, then

Re: [Bloat] dropbox, bbr and ecn packet capture

--- Begin Message --- On Sat, Apr 25, 2020 at 8:52 PM Jonathan Morton wrote: > > On 26 Apr, 2020, at 3:36 am, Dave Taht wrote: > > > > I just did a rather large dropbox download. They are well known to be > > using bbr and experimenting with bbrv2. So I fired off a capture > > during a big

Re: [Bloat] Excessive throttling with fq

On Wed, Feb 19, 2020 at 1:58 AM Alexey Ivanov wrote: > > FWIW, we recently noticed a similar issue with our CUBIC senders after > we've enabled FQ on them (4.15 kernel.) > > Disabling train detection in hystart did fix the problem: > > # echo 2 > /sys/module/tcp_cubic/parameters/hystart_detect >

Re: [Bloat] [bbr-dev] bbr, bbrv2 and cubic compared at dropbox

Hi Dave, Thanks for sharing this! neal On Tue, Dec 17, 2019 at 5:18 PM Dave Taht wrote: > > https://blogs.dropbox.com/tech/2019/12/evaluating-bbrv2-on-the-dropbox-edge-network/ > > -- > Make Music, Not War > > Dave Täht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-435-0729 > >

Re: [Bloat] DOCSIS cable modems that support PIE?

*From: *Colin Dearborn *Date: *Mon, May 13, 2019 at 11:49 AM *To: *Sebastian Moeller, Neal Cardwell *Cc: *bloat CM AQM was added as an optional feature in DOCSIS 3.0. I don't know of any > 3.0 modems where this was actually implemented though. > This feature requires no support from th

Re: [Bloat] DOCSIS cable modems that support PIE?

functionality? neal *From: *Sebastian Moeller *Date: *Mon, May 13, 2019 at 5:16 AM *To: *bloat, Neal Cardwell Hi Neal, > > As far as I can tell the PIE aqm is mandatory in all DOCSIS 3.1 CPEs, do > Al you need is a modem certified for 3.1 and probably also an DOCSIS ISP > supplying 3.1

[Bloat] DOCSIS cable modems that support PIE?

Anyone have a pointer to a cable modem model that is available for purchase and implements the DOCSIS 3.1 PIE mechanism? (So far, my searches for this have only found other people asking this question, rather than the answer. Apologies if I missed something that should be easy to find.) I'm

Re: [Bloat] when does the CoDel part of fq_codel help in the real world?

I believe Dave Taht has pointed out, essentially, that the "codel" part of fq_codel can be useful in cases where the definition of "flow" is not visible to fq_codel, so that "fq" part is inactive. For example, if there is VPN traffic, where the individual flows are not separable by fq_codel, then

Re: [Bloat] benefits of ack filtering

On Thu, Nov 30, 2017 at 10:55 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2017-11-30 at 09:51 -0500, Neal Cardwell wrote: > > On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet <eric.duma...@gmail.com > > > wrote: > > > I agree that TCP itself shoul

Re: [Bloat] benefits of ack filtering

On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet wrote: > I agree that TCP itself should generate ACK smarter, on receivers that > are lacking GRO. (TCP sends at most one ACK per GRO packets, that is > why we did not feel an urgent need for better ACK generation) > > It is

Re: [Bloat] TCP BBR over LTE

By the way, the slides are now available at: https://www.netdevconf.org/2.1/slides/apr7/chung-driving-tcps-on-highway-2.0.pdf neal On Fri, Apr 7, 2017 at 9:50 AM, Stephen Hemminger < step...@networkplumber.org> wrote: > Interesting talk at Netdev 2.1 > > Verizon testing TCP BBR over LTE. >

Re: [Bloat] Initial tests with BBR in kernel 4.9

y would be ideal), and post on a web site somewhere a pcap trace for one of the slow trials? For example: tcpdump -n -w /tmp/out.pcap -s 120 -i eth0 -c 100 & thanks, neal > > On 25 January 2017 at 23:01, Neal Cardwell <ncardw...@google.com> wrote: > >> On Wed

Re: [Bloat] TCP BBR paper is now generally available

>http://storage.sesse.net/bbr.pcap -- ssh+tar+gnupg I agree with Eric that for the ssh+tar+gnupg case the ACK stream seems like the culprit here. After about 1 second, the ACKs are suddenly very stretched and very delayed (often more than 100ms). See the attached screen shots. I like Eric's

Re: [Bloat] TCP BBR paper is now generally available

On Tue, Dec 6, 2016 at 12:20 PM, Steinar H. Gunderson < sgunder...@bigfoot.com> wrote: > On Sat, Dec 03, 2016 at 03:24:28PM -0800, Eric Dumazet wrote: > > Wait a minute. If you use fq on the receiver, then maybe your old debian > > kernel did not backport : > > > >

Re: [Bloat] TCP BBR paper is now generally available

:40 +0100, Steinar H. Gunderson wrote: >> On Fri, Dec 02, 2016 at 05:22:23PM -0500, Neal Cardwell wrote: >> > Of course, if we find important use cases that don't work with BBR, we will >> > see what we can do to make BBR work well with them. >> >> I have one thing t

Re: [Bloat] TCP BBR paper is now generally available

On Fri, Dec 2, 2016 at 3:32 PM, Jonathan Morton wrote: > > > On 2 Dec, 2016, at 21:15, Aaron Wood wrote: > > > > So, how is this likely to be playing with our qos_scripts and with cake? > > Cake’s deficit-mode shaper behaves fairly closely like an ideal

Re: [Bloat] [bbr-dev] Re: taking apart BBR's behaviors in flent

On Thu, Sep 22, 2016 at 8:09 AM, Alan Jenkins wrote: > On Wednesday, 21 September 2016 20:25:32 UTC+1, Dave Taht wrote: >> >> > Looking at cake_flowblind_noecn, BBR1 and BBR4 just kills both CUBIC >> > flows. >> > Same with PIE. >> >> Yep. The single queue AQMs

Re: [Bloat] [Cerowrt-devel] Comcast's NANOG slides re Bufferbloat posted (Oct 2016)

On Thu, Oct 20, 2016 at 8:15 AM, Rich Brown wrote: > > https://www.nanog.org/sites/default/files/20160922_Klatsky_First_Steps_In_v1.pdf Regarding these passages from the slide deck: What do the results suggest? There may be a tradeoff between upload

Re: [Bloat] [bbr-dev] taking apart BBR's behaviors in flent

On Wed, Sep 21, 2016 at 3:25 PM, Dave Taht wrote: > > So it seems my intuition was wrong, at least for these scenarios. It wasn't > > CUBIC that would kill BBR, it's the other way around. > > My intuition was that "delay based TCPs can't work on the internet!" - > and was