Re: [Bloat] A Transport Protocol's View of Starlink

[Stephen Hemminger via Bloat]

On Wed, 22 May 2024 06:16:17 -0700
Kenneth Porter via Bloat  wrote:

> This technical paper on Starlink by the chief scientist at APNIC crossed my 
> feed this week. [I thought I'd share it to the Starlink list here but my 
> application to join that list seems to have gotten stuck so I'll share it 
> here for now.]
> 
> 
> 
> >From the end of the paper:  
> 
> > While earlier TCP control protocols, such as Reno, have been observed to
> > perform poorly on Starlink connections, more recent TCP counterparts,
> > such as CUBIC, perform more efficiently. The major TCP feature that makes
> > these protocols viable in Starlink contexts is the use of Selective
> > Acknowledgement [11], that allows the TCP control algorithm to
> > distinguish between isolated packet loss and loss-inducing levels of
> > network congestion.
> >
> > TCP control protocols that attempt to detect the onset of network queue
> > formation can do so using end-to-end techniques by detecting changes in
> > end-to-end latency during intermittent periods of burst, such as BBR.
> > These protocols need to operate with a careful implementation of their
> > sensitivity to latency, as the highly unstable short-term latency seen on
> > Starlink connections, coupled with the 15-second coarse level latency
> > shifts have the potential to confuse the queue onset detection algorithm.
> >
> > It would be interesting to observe the behaviour of an ECN-aware TCP
> > protocol behaviour if ECN were to enabled on Starlink routing devices.
> > ECN has the potential to provide a clear signal to the endpoints about
> > the onset of network-level queue formation, as distinct from latency
> > variation.  

It frustrates me that all research still looks primarily at Reno, rather
than the congestion controls that are actually implemented in Linux and Windows
which are used predominately on the Internet.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Stephen Hemminger via Bloat]

On Wed, 7 Feb 2024 07:05:27 -0500
Dave Taht via Bloat  wrote:

> I also tend to think that attempting it in various cloudy
> environments and virtualization schemes, and with certain drivers, the
> side effects are not as well understood as I would like. For example,
> AWS's nitro lacks BQL as does virtio-net.

FYI - Microsoft Azure drivers don't do BQL either.
Both netvsc and mana.

The problem is that implementing BQL is not as easy as it looks
and has possibility of introducing bugs. One big customer with a stuck
connection totally negates any benefit!

For virtio, there have been several attempts at BQL and they never worked
perfectly.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Best approach for debloating Airbnb host?

[Stephen Hemminger via Bloat]

On Tue, 17 Oct 2023 06:26:17 -0700
Dave Taht via Bloat  wrote:

> > 2. What would I recommend? Obviously, inserting something with cake into 
> > the mix would help a lot. Even if they were willing to let me examine their 
> > entire network (Comcast router, Apple Airport in our Airbnb unit, other 
> > router?) I have no idea what kind of tar baby I would be touching. I don't 
> > want to become their network admin for the rest of time.

By now most home routers do have option for some form of QoS but may default to 
disabled.

The problem with interacting with mortals on technical topics is that you 
create a debt.
It is often a multi-hour effort to resolve and the expectation is that this is 
free.
So doing it for relatives (of course), fixing a local coffee shop where you 
know the owner (sure),
but dealing with a one time AirBnb doesn't seem worth it.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Easiest/most effective way to test software against adverse networks?

[Stephen Hemminger via Bloat]

On Sat, 5 Aug 2023 13:35:40 -0400
Sean DuBois via Bloat  wrote:

> I am working on improving Pion's Google Congestion Control algorithm
> https://github.com/pion/interceptor/tree/master/pkg/gcc. As I start to use
> it in more real world networks I find flaws.
> 
> How are people testing software today? Is 'Traffic Control' the best option?


Netem works but there are artifacts from the emulation.

But my view on congestion control is that this sounds like Google
doing NIH reinvention. Happens when you hire a lot of smart people

"Those who don't know history are doomed to repeat it"
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Cake] Two questions re high speed congestionmanagement anddatagram protocols

[Stephen Hemminger via Bloat]

On Mon, 10 Jul 2023 23:27:46 +0200
Sebastian Moeller  wrote:

> For what it is worth, the tsv working group is considering whether to process 
> mp-dccp on the standards track, but then the IETF seems not to care too 
> deeply about open-source licence compliance. Or recent kernel implementations 
> or implementations that have a realistic path towards mainline inclusion... 
> but I digress.

The issue is the MP-DCCP implementation is derived from the existing kernel 
DCCP which is GPL-v2.
You can't go randomly mixing proprietary code and GPL code in the kernel.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Cake] Two questions re high speed congestionmanagement anddatagram protocols

[Stephen Hemminger via Bloat]

On Wed, 28 Jun 2023 10:32:32 -0400 (EDT)
"David P. Reed"  wrote:

> How to find a kernel maintainer to care about DCCP, seems to be the question 
> for Linux.
> I am tempted... Not to get involved with IETF "barriers" (what a mess, given 
> the folks in IETF who resisted in AQM, I wouldn't last a minute), but to keep 
> DCCP support alive.
> The barrier here is getting accepted as a Linux maintainer, which is a 
> different issue entirely, looking at my last two experiences with submitting 
> simple bug fixes to the kernel, which were nightmares. I don't have the 
> commitment to become accepted as a maintainer.
> But it seems good to maintain DCCP, despite its lack of popularity as an IETF 
> standard. It does deal with CC in a way that simplifies use of UDP for 
> serious work.

Interesting that there is an out of tree DCCP, complete with likely GPL license 
violation.
https://github.com/telekom/mp-dccp
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Two questions re high speed congestion management anddatagram protocols

[Stephen Hemminger via Bloat]

On Tue, 27 Jun 2023 12:47:01 -0700 (PDT)
David Lang  wrote:

> On Mon, 26 Jun 2023, David P. Reed via Bloat wrote:
> 
> > Sorry for top posting, but ... Bigger question:
> > Why would DCCP be deprecated by Linux kernel?
> > Who makes that decision? Who argues against it?  
> 
> Linus or the networking maintaners make the decision.
> 
> Usually things get pulled from the kernel because there are updates that need 
> to 
> be made to the code (to match changes elsewhere in the kernel or because of 
> security issues) and there isn't a maintainer who works on the code in a 
> resonable time. This means that the maintainers for the general code area (in 
> this case networking maintainers) will need to do extra work in an area they 
> aren't that interested in (and, especially in the case of hardware, may not 
> have 
> the ability to test). They do some of it, especially if it's commonly used, 
> but 
> eventually either another maintainer steps up, or it goes away
> 
> David Lang

See 
https://patchwork.kernel.org/project/netdevbpf/patch/20230614194705.90673-3-kun...@amazon.com/
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Two questions re high speed congestion management anddatagram protocols

[Stephen Hemminger via Bloat]

On Mon, 26 Jun 2023 23:41:59 -0400 (EDT)
"David P. Reed"  wrote:

> Sorry for top posting, but ... Bigger question:
> Why would DCCP be deprecated by Linux kernel?
> Who makes that decision? Who argues against it?

No one uses it, and unused protocols are targeted by hackers.
And there are few tests and no maintainer.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Two questions re high speed congestion management and datagram protocols

[Stephen Hemminger via Bloat]

On Sat, 24 Jun 2023 14:41:52 -0400 (EDT)
"David P. Reed via Bloat"  wrote:

> I also was looking back to DCCP as a useful way to get a UDP that handled 
> congestion without engaging the higher layers, and preserving the other 
> flexibility of UDP.

DCCP never got widely used, and Linux is on the path of deprecating it.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] why do people still study RED?

[Stephen Hemminger via Bloat]

On Wed, 31 May 2023 16:28:14 -0600
Dave Taht via Bloat  wrote:

> An otherwise good paper on RED vs drop tail here:
> 
> https://arxiv.org/pdf/2303.10220.pdf
> 
> Is it because we completely lack any analytical methods for taking a
> hard look at drop or marking from the head, as codel does, or the
> effect of the fq in fq_codel?
> 
> I keep hoping somehow, somewhere, someone would show up with the tools
> to explain the results I got here:
> 
> https://blog.cerowrt.org/post/juniper/
> 

Probably because that is what all the big router vendors had available in 2010.
Hopefully, they have started do something smarter in HW.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] hystart++

[Stephen Hemminger via Bloat]

On Sun, 28 May 2023 06:46:48 -0600
Dave Taht via Bloat  wrote:

> Does a linux implementation of this exist? It looks promising...
> 
> https://datatracker.ietf.org/doc/html/rfc9406
> 

Not that I know of. Contact the authors and they may be able to help.
Microsoft is more open source friendly now, but obviously all the research is
on Windows implementation.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

[Bloat] Traffic shaping for evil?

[Stephen Hemminger via Bloat]

This showed up on Human Infrastructure mailing list and others might be
interested.

https://adriano.fyi/post/2023/2023-04-16-att-traffic-shaping-makes-websites-unusable/
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] WSL2 + fq_codel

[Stephen Hemminger via Bloat]

Should be whatever the Linux distro default is. Most people use Ubuntu

On Mon, Feb 27, 2023, 4:11 AM Maximilian Bachl 
wrote:

> Yes, the default interface of WSL2 seems to use fq_codel:
>
> $ tc qdisc show dev eth0
> qdisc mq 0: root
> qdisc fq_codel 0: parent :8 limit 10240p flows 1024 quantum 1514 target
> 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :7 limit 10240p flows 1024 quantum 1514 target
> 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :6 limit 10240p flows 1024 quantum 1514 target
> 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :5 limit 10240p flows 1024 quantum 1514 target
> 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target
> 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target
> 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target
> 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target
> 5.0ms interval 100.0ms memory_limit 32Mb ecn
>
> On Sat, Feb 25, 2023 at 11:07 PM Dave Taht via Bloat <
> bloat@lists.bufferbloat.net> wrote:
>
>> On Sat, Feb 25, 2023 at 12:54 PM Stephen Hemminger
>>  wrote:
>> >
>> > On Sat, 25 Feb 2023 15:37:02 -0500
>> > Michael Richardson via Bloat  wrote:
>> >
>> > > Dave Taht via Bloat  wrote:
>> > > > I so want to believe... I so want to believe... can anyone
>> confirm?
>> > >
>> > > >
>> https://raw.githubusercontent.com/microsoft/WSL2-Linux-Kernel/linux-msft-wsl-5.15.y/Microsoft/config-wsl
>> > >
>> > > But, AFAIK, WSL isn't a kernel.  It's an implementation of the Linux
>> ABI on
>> > > top of Windows service(s).  If you told me that they build some of it
>> from
>> > > actual Linux kernel sources, I'd believe you.  (Rather like
>> User-Mode-Linux)
>> > >
>> > > If you told me that they have a kernel that they build for when they
>> actually
>> > > spin up an actual VM (such as to run containers) that would also be
>> unsurprising.
>> > >
>> > > > ...
>> > >
>> > > > CONFIG_NET_SCH_DEFAULT=y
>> > > > CONFIG_DEFAULT_FQ_CODEL=y
>> > > > # CONFIG_DEFAULT_PFIFO_FAST is not set
>> > > > CONFIG_DEFAULT_NET_SCH="fq_codel"
>> > >
>> > > It would be nice if the billion windows desktops started doing
>> > > something better, but I don't think it will help observed latency.
>> > > The real question is what the default schedule for the default Azure
>> Linux VM
>> > > is.
>> > >
>> >
>> > I think WSL2 is actually a full Linux VM running in Hyper-V.
>>
>> Yes, it is. But it is kind of unknown how the underlying network
>> interface is behaving in this case, as well as what the actual default
>> qdisc is, and this not just a random gist. It was VERY exciting to see
>> that gist go by...
>>
>> are there no windows users on this list? :/ We long ago should have
>> pursued at least flent, and a TCP_INFO equivalent sampling method for
>> windows. The closest thing we have for windows is the rust-based:
>> https://github.com/Zoxc/crusader
>>
>> --
>> A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/
>> Dave Täht CEO, TekLibre, LLC
>> ___
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
>
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] WSL2 + fq_codel

[Stephen Hemminger via Bloat]

On Sat, 25 Feb 2023 15:37:02 -0500
Michael Richardson via Bloat  wrote:

> Dave Taht via Bloat  wrote:
> > I so want to believe... I so want to believe... can anyone confirm?  
> 
> > 
> https://raw.githubusercontent.com/microsoft/WSL2-Linux-Kernel/linux-msft-wsl-5.15.y/Microsoft/config-wsl
>   
> 
> But, AFAIK, WSL isn't a kernel.  It's an implementation of the Linux ABI on
> top of Windows service(s).  If you told me that they build some of it from
> actual Linux kernel sources, I'd believe you.  (Rather like User-Mode-Linux)
> 
> If you told me that they have a kernel that they build for when they actually
> spin up an actual VM (such as to run containers) that would also be 
> unsurprising.
> 
> > ...  
> 
> > CONFIG_NET_SCH_DEFAULT=y
> > CONFIG_DEFAULT_FQ_CODEL=y
> > # CONFIG_DEFAULT_PFIFO_FAST is not set
> > CONFIG_DEFAULT_NET_SCH="fq_codel"  
> 
> It would be nice if the billion windows desktops started doing
> something better, but I don't think it will help observed latency.
> The real question is what the default schedule for the default Azure Linux VM
> is.
> 

I think WSL2 is actually a full Linux VM running in Hyper-V.


pgpk90lJoAiuz.pgp
Description: OpenPGP digital signature
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Fwd: [New post] How Good is FWA Wireless?

[Stephen Hemminger via Bloat]

On Wed, 8 Feb 2023 16:43:59 -0800
Dave Taht via Bloat  wrote:

> On Wed, Feb 8, 2023 at 2:41 PM Luis A. Cornejo  
> wrote:
> >
> > As a former T-mobile HSI customer, I can attest the horrible queue 
> > management. The deprioritization was so bad that it became basically 
> > unusable, even a ping or DNS lookup just lagged. I latched to a tower near 
> > the interstate about 2 miles away. I knew when there was an accident at the 
> > interstate, my online experience correlated very well.  
> 
> I ranted over here about how bad just the depriotization could become,
> and also pointed to a flaw, I believe, in how long devices hold onto
> packets in that case. I fear that when the network is getting toasty,
> and comes back online that there is a thundering herd of devices,
> enormous backlogs of stale syns, and so on that hit it, and what is in
> place is some sort of timed rate limiter to deal with it, not very
> well. It is the only explanation I have for seeing pings come back on
> 1s intervals...
> 
> https://blog.cerowrt.org/post/flaws_in_flent/
> 

I think this is leftover circuit switch telco mindset. Everyone 
needs/wants/will buy their own slice.
It looks like they keep trying and trying to see value added networking. But 
well-designed best effort
is always cheaper, more efficient and overall faster. We heard this story 
before with MPLS, ATM, etc.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Rpm] the grinch meets cloudflare's christmas present

[Stephen Hemminger via Bloat]

On Wed, 4 Jan 2023 15:11:34 -0500
David Collier-Brown via Bloat  wrote:

> On 1/4/23 15:02, rjmcmahon via Bloat wrote:
> > Curious to why people keep calling capacity tests speed tests? A semi 
> > at 55 mph isn't faster than a porsche at 141 mph because its load 
> > volume is larger.  
> 
> They're trying to make the results sound more attractive. They know the 
> customer would prefer a porsche, but what they have to sell them are 
> semi-trailers.
> 
> --dave
> 
> 
> ___
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Interesting, the cloudflare test gets much worse results than others.
It maybe because it defaults to IPV6 by default and ISP does not support
real IPV6.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Fwd: NANOG 87: Call for Presentations | N86 PC Picks + More

[Stephen Hemminger via Bloat]

On Thu, 10 Nov 2022 08:58:39 -0800
Dave Taht via Bloat  wrote:

> I keep hoping that someone from starlink will start showing up at
> traditional venues such as this.

How is Starlink going, now that Elon has shown how he can screw up a company.
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] [Make-wifi-fast] The most wonderful video ever about bufferbloat

[Stephen Hemminger via Bloat]

On Wed, 19 Oct 2022 14:33:28 -0700 (PDT)
David Lang via Bloat  wrote:

> On Wed, 19 Oct 2022, Stuart Cheshire via Bloat wrote:
> 
> > On Mon, Oct 17, 2022 at 5:02 PM Stuart Cheshire  wrote:
> >  
> >> Accuracy be damned. The analogy to common experience resonates more.  
> >
> > I feel it is not an especially profound insight to observe that, “people 
> > don’t like waiting in line.” The conclusion, “therefore privileged people 
> > should get to go to the front,” describes an airport first class checkin 
> > counter, Disney Fastpass, and countless other analogies from everyday life, 
> > all of which are the wrong solution for packets in a network.  
> 
> the 'privileged go first' is traditional QoS, and it can work to some extent, 
> but is a nightmare to maintain and gets the wrong result most of the time.

A lot of times when this is proposed it has some business/political motivation.
It is like "priority boarding" for Global Services customers.
Not solving a latency problem, instead making stakeholders happy.

> AQM (fw_codel and cake) are more the 'cash only line' and '15 items or less' 
> line, they speed up the things that can be fast a LOT, while not 
> significantly 
> slowing down the people with a full baskets (but in the process, it shortens 
> the 
> lines for those people with full baskets)
> 
> >> I think the person with the cheetos pulling out a gun and shooting 
> >> everyone in front of him (AQM) would not go down well.  
> >
> > Which is why starting with a bad analogy (people waiting in a grocery 
> > store) inevitably leads to bad conclusions.
> >
> > If we want to struggle to make the grocery store analogy work, perhaps we 
> > show 
> > people checking some grocery store app on their smartphone before they 
> > leave 
> > home, and if they see that a long line is beginning to form they wait until 
> > later, when the line is shorter. The challenge is not how to deal with a 
> > long 
> > queue when it’s there, it is how to avoid a long queue in the first place.  
> 
> only somewhat, you aren't going to have people deciding not to click on a 
> link 
> because the network is busy, and if you did try to go that direction, I would 
> fight you. the prioritization is happening at a much lower level, which is 
> hard 
> to put into an analogy
> 
> even with the 'slowing' of bulk traffic, no traffic is prevented, it's just 
> that 
> they aren't allowed to monopolize the links.
> 
> This is where the grocery store analogy is weak, the reality would be more 
> like 
> 'the cashier will only process 30 items before you have to step aside and let 
> someone else in', but since no store operates that way, it would be a bad 
> analogy.

Grocery store analogies also breakdown because packets are not "precious"
it is okay to drop packets. A lot of AQM works by doing "drop early and often"
instead of "drop late and collapse".

> 
> >> Actually that analogy is fairly close to fair queuing. The multiple 
> >> checker analogy is one of the most common analogies in queue theory 
> >> itself.  
> >
> > I disagree. You are describing the “FQ” part of FQ_CoDel. It’s the “CoDel” 
> > part of FQ_CoDel that solves bufferbloat. FQ has been around for a long 
> > time, 
> > and at best it partially masked the effects of bufferbloat. Having more 
> > queues 
> > does not solve bufferbloat. Managing the queue(s) better solves bufferbloat.
> >  
> >> I like the idea of a guru floating above a grocery cart with a better 
> >> string of explanations, explaining
> >>
> >>   - "no, grasshopper, the solution to bufferbloat is no line... at all".  
> >
> > That is the kind of thing I had in mind. Or a similar quote from The 
> > Matrix. 
> > While everyone is debating ways to live with long queues, the guru asks, 
> > “What 
> > if there were no queues?” That is the “mind blown” realization.  
> 
> In a world where there is no universal scheduler (and no universal knowlege 
> to 
> base any scheduling decisions on), and where you are going to have malicious 
> actors trying to get more than their fair share, you can't rely on voluntary 
> actions to eliminate the lines.
> 
> There are data transportation apps that work by starting up a large number of 
> connections in parallel for the highest transfer speeds (shortening slow 
> start, 
> reducing the impact of lost packets as they only affect one connection, etc). 
> This isn't even malicious actors, but places like Hollywood studios sending 
> the raw movie footage around over dedicated leased lines and wanting to get 
> every bps of bandwidth that they are paying for used.
> 
> David Lang

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Researchers discover major roadblock in alleviating network congestion

[Stephen Hemminger via Bloat]

On Fri, 5 Aug 2022 00:45:12 +0300
Jonathan Morton via Bloat  wrote:

> > On 4 Aug, 2022, at 3:21 pm, Bjørn Ivar Teigen via Bloat 
> >  wrote:
> > 
> > Main take-away (as I understand it) is something like "In real-world 
> > networks, jitter adds noise to the end-to-end delay such that any algorithm 
> > trying to infer congestion from end-to-end delay measurements will 
> > occasionally get it wrong and this can lead to starvation". Seems related 
> > to Jaffe's work on network power (titled "Flow control power is 
> > non-decentralizable").   
> 
> Hasn't this been known for many years, as a consequence of experience with 
> TCP Vegas?
> 
>  - Jonathan Morton

It seems like BBR developers thought they could do better. Unfortunately, 
papers with negative
results never seem to get written or published ;-(
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat