Re: [Bloat] RED 13 years later

A big issue is that "average queue length" was and is a terrible indicator of congestion. But I think the first "bug" Van was referring to was the original RED "control law" - I asked him why he thought it would work as it really ends up looking like a step function which your first control

Re: [Bloat] [NNagain] CFP march 1 - network measurement conference

Can I give an email "thumbs up" to Bill Woodcock's email? That information is certainly there in TCP. I don't know how much of QUIC is in the clear. On 12/6/23 6:22 PM, Bill Woodcock via Bloat wrote: On Dec 6, 2023, at 22:46, Sauli Kiviranta via Nnagain wrote: What would be a

Re: [Bloat] not a bad 10 years...

On 10/31/22 7:46 PM, Dave Taht via Bloat wrote: I remember when I thought videoconferencing quality like this, was good. VJ, on Kathie's codel, and a ton of queue theory that seems to have sunk in around the world, with a talk that still seems fresh. https://archive.org/details/video1_20191129

Re: [Bloat] Ookla - Introducing a Better Measure of Latency

a ping by any other name... Has anyone ever done a rigorous study to see how well ping delays correspond to the delay that information-carrying packets experience? On 5/12/22 10:15 AM, Christoph Paasch via Bloat wrote: Ookla's measure of "loaded latency":

Re: [Bloat] Credit and/or collaboration on a responsiveness metric?

In coming up with metrics, I would really encourage you to think about making use of tdigest to gather statistics in some of your on-line measurement. I'm not sure users see "average" behavior. I mean if someone is getting great latency numbers most of the time, with a small percentage of

Re: [Bloat] Trouble Installing PPing in MacOS

On 2/26/21 4:56 AM, Jason Iannone wrote: ... > passively monitor production flows to get a novel sense of end to end > performance per flow. I don't know of any other passive monitoring > technique, beyond a port mirror + a whole gang of systems, that can > provide this level of detail. Please

Re: [Bloat] lte + cable latency improvement

On 1/15/19 12:02 AM, Dave Taht wrote: > https://www.cablelabs.com/enabling-the-cable-networks-for-mobile-backhaul/ > > Hmm. From the linked article: > Additionally, in building the PoC, we have accumulated expertise on > how to perfect the BWR algorithm to optimally predict the amount of > data

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

On 11/27/18 3:17 PM, Dave Taht wrote: ... > > but now that we all have bedtime reading, I'm going to go back to > hacking on libcuckoo. :) > > Geez, louise. As if everyone doesn't have enough to do! I apologize. I did not mean for anyone to completely read the links I sent, just look at the

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

I have been kind of blown away by this discussion. Jim Gettys kind of kicked off the current wave of dealing with full queues, dubbing it "bufferbloat". He wanted to write up how it happened so that people could start on a solution and I was enlisted to get an article written. We tried to draw on

Re: [Bloat] [Cerowrt-devel] closing up my make-wifi-fast lab

Yes, Dave, thanks for being the guy with the lantern keeping this work in front of people and organizing work and measurements. As a "shiny object" person who likes to move on to the next "interesting" problem, I really appreciate that you stuck it out and worked to make solutions a reality, not

Re: [Bloat] measuring "flows-in-progress" over an interval

If you do not find a tool, you might try building your own. Using libtins http://libtins.github.io/ makes it much easier to build C++ programs that operate on sniffed packets than it used to be. I used it in pping https://github.com/pollere/pping and connmon for TCP flows and in some non-public

Re: [Bloat] (no subject)

On 6/19/18 11:56 PM, Sebastian Moeller wrote: > > Addendum: when running speedtests on cable for the purpose of estimating the > "true" docsis shaper goodput one needs to take care to not be fooled by > transient bandwidth allowances like powerboost but rather one needs to find > the

Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved

On 6/21/18 12:17 PM, Dave Taht wrote: > On Thu, Jun 21, 2018 at 9:43 AM, Kathleen Nichols wrote: >> On 6/21/18 8:18 AM, Dave Taht wrote: >> >>> This is a case where inserting a teeny bit more latency to fill up the >>> queue (ugh!), or a driver having some way to

Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved

On 6/21/18 8:18 AM, Dave Taht wrote: > This is a case where inserting a teeny bit more latency to fill up the > queue (ugh!), or a driver having some way to ask the probability of > seeing more data in the > next 10us, or... something like that, could help. > Well, if the driver sees the

Re: [Bloat] Tuning fq_codel: are there more best practices for slow connections? (<1mbit)

On 11/2/17 1:25 AM, Sebastian Moeller wrote: > Hi Y. > > >> On Nov 2, 2017, at 07:42, Y wrote: >> >> hi. >> >> My connection is 810kbps( <= 1Mbps). >> >> This is my setting For Fq_codel, >> quantum=300 >> >> target=20ms >> interval=400ms >> >> MTU=1478 (for PPPoA) >> I

Re: [Bloat] How to "sell" improvement

That's a good idea in general, but what are you measuring for your "actual performance"? Raw throughput? Goodput (which requires a bit of processing)? Then what about delay? On 11/28/16 9:41 AM, David Collier-Brown wrote: > Put the speed-test /into the router/, with a big red button to turn >

Re: [Bloat] Fixing bufferbloat in 2017

Well, it would be good to know where the congestion is coming from, i.e. saying that "the network is congested" doesn't say which network. Since our downlink got upgraded, there is rarely an issue there but from time to time the comcast network just "goes down" in that it seems that nothing gets

Re: [Bloat] Fixing bufferbloat in 2017

I never have any problem hearing you, Dave. Random stuff in-line. On 11/27/16 1:24 PM, Dave Taht wrote: > There *are* 430+ other minds on this mailing list, and probably a few > AIs. > > Sometimes I worry that most of our postings go into spamboxes now, > or that we've somehow completely

Re: [Bloat] Bufferbloat test measurements

Hi, Justin, Thanks for the explanations. So the grade is for the user not the ISP? I just have to point out that the below jumped out at me a bit. A user can fully use the link bandwidth capacity and not have an unacceptable latency. After all, that's the goal of AQM. But, yes, there are those

Re: [Bloat] Bufferbloat test measurements

would confuse > people. And the tests they're used to / compare with, show idle latency > instead.) > > On 27/08/16 16:19, Kathleen Nichols wrote: >> Yeah. >> >> I admit to muddying the waters because I think of the size of a buffer as >> being in megabytes and

Re: [Bloat] Bufferbloat test measurements (was: Open Source Speed Test)

Yeah. I admit to muddying the waters because I think of the size of a buffer as being in megabytes and the size of a queue (latency) as being in milliseconds. I think the tests attempt to measure the worst possible latency/queue that can occur on a path. On 8/27/16 4:46 AM, Rich Brown wrote: >

Re: [Bloat] Open Source Speed Test (was fast.com - Netflix's speed monitoring)

in-line On 8/26/16 4:20 PM, David Lang wrote: > On Fri, 26 Aug 2016, Kathleen Nichols wrote: > >> I think it might be useful to say these tests measure the maximum >> *potential* for >> bufferbloat. That is, they plumb the depths of the buffers in the path. >>

[Bloat] some experiments with downstream queue delay

Pollere has been working on passive monitoring methods, in particular on monitoring delay. This has something of a slog, but whenever there is data, it's pretty fun. I've been running our prototype in my home network and wrote up the delay results in a note:

Re: [Bloat] new public web tests for bufferbloat

Are these tools all active probes? It looks that way to me. Kathie On 6/2/16 1:05 PM, Colin Dearborn wrote: > Plenty of easy ways to do v4 and v6. > DNS can be built to only have hosts for v4 or v6, and you run two tests, one > to each set of hosts. > Comcast has been doing it forever.

Re: [Bloat] [Cake] dslreports and inbound rate shaping

On 5/21/15 9:21 AM, Jonathan Morton wrote: On 19 May, 2015, at 22:17, Dave Taht dave.t...@gmail.com wrote: So I finished writing up my thoughts on bobbie, http://www.bufferbloat.net/projects/codel/wiki/Bobbie which might work better than anything on the table in the face of huge bursts

Re: [Bloat] [Cake] dslreports and inbound rate shaping

It sounds like you are defining congestion as packets experiencing 5ms of delay over a period of 5ms. When you evaluate this, what metrics do you use to evaluate the effect on the applications using this buffer? Kathie On 5/21/15 8:26 AM, Jonathan Morton wrote: When Codel is applied

Re: [Bloat] vint cerf on c-span this morning

omg On 5/4/15 1:41 PM, Dave Taht wrote: http://www.c-span.org/video/?325750-1/google-vice-president-vint-cerf-future-internet see 7:30 in... ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Questions about the use of HTB fq_codel in simple.qos, simplest.qos

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just to clarify...I wrote the sfqcodel code in ns using existing sfq code so I could put something together quickly to show the benefits, most specifically, of binning acks and other short packets separately from longer data transfer packets. At the

Re: [Bloat] We are having it all upside down...

If you just look at the efficiency measures, the bigger satellites are going to make it easier to for an unfriendly to disrupt global communications. I think, on the whole, given a scrappy communications protocol, I'd prefer the lemonade. Kathie

[Bloat] note on CoDel and bursty MACs

I've added a new note on CoDel. This is about CoDel with bursty MACs where packets don't leave the queue at a steady rate. If you are interested, see: http://www.pollere.net/CoDelnotes.html Kathie ___ Bloat mailing list

Re: [Bloat] [Codel] [Cerowrt-devel] FQ_Codel lwn draft article review

It would be me that tries to say stochastic flow queuing with CoDel as I like to be accurate. But I think FQ-Codel is Flow queuing with CoDel. JimG suggests smart flow queuing because he is ever mindful of the big audience. On 11/27/12 4:27 PM, Paul E. McKenney wrote: On Tue, Nov 27, 2012 at