I tried to read the article, and had to go back and forth between reading about terms and etc, because I'm not _that_ familiar in the space. But previously I could understand Cloudflare's blog posts.
This one just feels... off. The buildup just doesn't feel right.
The fact that there is an Em Dash (sorry...) in the code tells me that it's at least AI assisted, which explains the vibe the article emanates.
And once I finally made it to the end I read the following:
> If you're interested in congestion control, transport protocols, or contributing to open-source networking code, check out the quiche repository. We're always looking for talented engineers who love digging into problems like these, please explore our open positions.
You don't add that to your blog-posts 5 days after laying off 20% of the company, regardless of whether they're sales people or engineers. If you want to add it, delay the post by 2 weeks.
Equally, there is only 1 role open in Engineering, and it's an intern role, posted yesterday:
> it's at least AI assisted, which explains the vibe the article emanates
You're being too kind -- "The [b]epoch[b] is the reference timestamp CUBIC". Weird style to have random bold words. Its a blog post for the sake of it - no real takeaway. Well, there is the takeaway section that's a special summary of the article, instead.
I can see why they rewrote QUIC in Rust and for use in userspace, though going the in-house approach would warrant keeping an eye on the relevant kernel commits like a hawk to avoid missing bug fixes like these. These in-house implementations tend to have less eyeballs than the kernel.
I found it interesting that Cloudflare is not yet using BBR as the default in quiche. CUBIC's recovery in this day and age, and especially in datacenters with large pipes, seems so slooow to me. Almost two seconds with no loss whatsoever till achieving BDP again and then shooting itself in the foot every time it hits the ceiling. Each one of those losses a retransmission.
> though going the in-house approach would warrant keeping an eye on the relevant kernel commits like a hawk to avoid missing bug fixes like these. These in-house implementations tend to have less eyeballs than the kernel.
This is somewhat funny to read because this specific issue in CUBIC (sudden CWND jump upon existing quiescence) was originally discovered in Google's QUIC library and then later reported to the team working on the TCP stack. I know this because I was the one who found that bug back in 2015.
That said, congestion control algorithms are really prone to logic bugs, and very subtle changes in the algorithm can often lead to dramatically different outcomes. Because of that, there's a lot of value in running congestion control code that has been tested on a wide variety of real Internet traffic.
I think a audited algorithm where each type is strictly defined like int32 added to that really help with what exactly should be inputted to it so it remains correct.
> I can see why they rewrote QUIC in Rust and for use in userspace
As far as I know, while they might have either way, they did not ("rewrite QUICK [...] for use in userspace"): the linux kernel implementation only landed late 2025. Quiche was started ca 2018 (that's when Cloudflare started beta-deploying QUIC, the first public alpha of quiche was january 2019).
I don't know that there even was an in-kernel implementation of quic before msquic.sys which I believe first shipped in Server 2022 circa mid 2021 (and is used as the implementation backend by MsQuic on Server 2022 and W11).
I think the original commenter confused taking the CUBIC implementation from the kernel and rewriting that in Rust for use in their QUIC implementation or they just jumbled their wording. It does make sense to use an existing battle tested implementation of a congestion algorithm because there are potential many real world failure modes that you might not anticipate if you try and write an implementation from scratch.
What jumps out to me is that this is a success story of using a non-trivial test to illuminate an important but hard to observe bit of algorithm. I appreciate the engineering grit to put in a complex test like this, and follow it up when the graph does not have the expected shape.
Imagine your team does not want to write a test because it's too much work or hard to model - this is a great example to bring up.
a Congestion Control Algorithm -- which uses various signals (mostly dropped packets) to try to estimate the available bandwidth and avoid network connection.
After some searching apparently it means “congestion control algorithm”. Definitely should have been defined in the article, especially since they have a whole section dedicated to explaining what it is.
Looking at the last plot, it seems like the backoff is roughly 1/5 of the total bandwith and it happens every 50 ms or so. Wouldn't it make sense to reduce the backoff and the growth speed if a backoff occurs repeatedly in rapid succession? We want to maximize the area under the curve (transmitted packages), right?
As per the article, CCAs aim to maximize data transfer by inferring the "available bandwidth" of the network. CUBIC relies primarily on packet loss as a congestion signal. For recovery, CUBIC's window size is a cubic function of time since the last congestion event.
After the initial packet loss triggered purposefully the first two seconds in this experiment, the only thing which could cause loss is the network queue (i.e. a simple tail drop, fq-codel, etc) which cannot process packets faster than they can arrive. At this point the link is saturated. The loss becomes a signal for CUBIC to reduce its window. This causes the oscillations you pointed out.
Unlike CUBIC, BBR [0] uses a model-based approach that estimates the available bandwidth and leaves some headroom kind of like you suggest to achieve higher throughput, and doesn't react as aggressively to loss as CUBIC.
The line that stuck with me: "Recovery after congestion collapse is an uncommon regime, but it is exactly the regime a congestion controller exists to handle."
This generalizes well beyond congestion control.
Most control loops have the same property. The path the system follows 99% of the time gets well-exercised; the path it falls into when things go wrong is the path you actually need to be correct on. There's usually no way to discover the bug until you deliberately drive the system into the bad regime and watch it try to climb out.
I _believe_ i've been having some connectivity issues related to this. Where the site acts like it's down but you refresh the page and it works. The solution is to disable the HTTP-3/QUIC toggle in Cloudflare. Some discussion here: https://xenforo.com/community/threads/page-could-not-be-load...
May not be related, but it might. It only recently started happening to me/our sites in the past couple of days.
The heading content and structure is the biggest tell IMO. Even shitty highschool kids don't write like that.
I don't understand where or how AI picked up that habit, because it's self evidently terrible. It makes it clear how low signal AI based writing is. The writing is like the music in shitty blockbusters; engineered to make you feel, rather than to actually structure the content or provide meaningful sections.
Compare this writeup to the Pixter writeup, where sections feel natural and not "scripted" like this.
I don’t get it. Unlike a lot of the technical article slop that is posted here, this obviously had a lot of human thought and effort put into the prompt.
The LLM pass (unsurprisingly) made it worse.
For example:
The results were conclusive: 100% pass rate, showing Reno recovered cleanly after the loss phase, and revealing that this is a CUBIC-related bug.
Look, I’m reading a description of a Linux kernel network congestion bug. I don’t need the hand-holding.
Yeah, you aren't selling anything. "Reno has a 100% pass rate for recovering cleanly after the loss phase, so the bug is almost certainly related to CUBIC" is a perfectly fine technical text.
Another LLM tell is that they penalize repetition so they'll use as many synonyms as possible. You may end up recognizing the same concept being rehashed with synonyms constantly. You can look up examples of thie as "elegant variation"
In one of the languages I read, journalists do this when quoting someone and it pisses me off. Instead of "said", they'll cycle through the same 6-7 synonyms. Instead of just quoting everything together, they break it up.
So instead of:
> President Jackson said "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.".
They'll do something like:
> President Jackson noted that "Lorem ipsum dolor sit amet". The head of state also remarked that "consectetur adipiscing elit" while emphasizing that "sed do eiusmod tempor incididunt ut labore et dolore magna aliqua".
> "Ut enim ad minim veniam, quis nostrud exercitation", categorically proclaimed the former business tycoon. He concluded that "ullamco laboris nisi ut aliquip ex ea commodo consequat".
I've seen this way before LLMs and how much it's used varies a bit from language to language. But it's so formulaic, I can't help but imagine some brain-dead moron sitting in front of the keyboard, trying to make 5 paragraphs from 2 sentences someone said without adding anything else.
Also, not a single takeaway about how to prevent that very preventable issue in the first place, as you allude to.
I wonder what happened with the very hardcore engineering that used to happen at Cloudflare and was published? Almost every blog post today seems to expose some weirdness at Cloudflare, rather than highlighting excellence in engineering, what changes? Been slowly changing over the years, did they change their hiring practices or something?
The test is the hardcore engineering tell here. The test is dialed in on the key area, and when the graph wasn't coming out the right shape, they kept at it. Plus one from me!
This one just feels... off. The buildup just doesn't feel right.
The fact that there is an Em Dash (sorry...) in the code tells me that it's at least AI assisted, which explains the vibe the article emanates.
And once I finally made it to the end I read the following:
> If you're interested in congestion control, transport protocols, or contributing to open-source networking code, check out the quiche repository. We're always looking for talented engineers who love digging into problems like these, please explore our open positions.
You don't add that to your blog-posts 5 days after laying off 20% of the company, regardless of whether they're sales people or engineers. If you want to add it, delay the post by 2 weeks.
Equally, there is only 1 role open in Engineering, and it's an intern role, posted yesterday:
https://www.cloudflare.com/careers/ (filter by Engineering).
Did they lay off their PR team as well?
You're being too kind -- "The [b]epoch[b] is the reference timestamp CUBIC". Weird style to have random bold words. Its a blog post for the sake of it - no real takeaway. Well, there is the takeaway section that's a special summary of the article, instead.
I found it interesting that Cloudflare is not yet using BBR as the default in quiche. CUBIC's recovery in this day and age, and especially in datacenters with large pipes, seems so slooow to me. Almost two seconds with no loss whatsoever till achieving BDP again and then shooting itself in the foot every time it hits the ceiling. Each one of those losses a retransmission.
This is somewhat funny to read because this specific issue in CUBIC (sudden CWND jump upon existing quiescence) was originally discovered in Google's QUIC library and then later reported to the team working on the TCP stack. I know this because I was the one who found that bug back in 2015.
That said, congestion control algorithms are really prone to logic bugs, and very subtle changes in the algorithm can often lead to dramatically different outcomes. Because of that, there's a lot of value in running congestion control code that has been tested on a wide variety of real Internet traffic.
https://doi.org/10.1145/3452296.3472912
Toward formally verifying congestion control behavior | Proceedings of the 2021 ACM SIGCOMM 2021 Conference
As far as I know, while they might have either way, they did not ("rewrite QUICK [...] for use in userspace"): the linux kernel implementation only landed late 2025. Quiche was started ca 2018 (that's when Cloudflare started beta-deploying QUIC, the first public alpha of quiche was january 2019).
I don't know that there even was an in-kernel implementation of quic before msquic.sys which I believe first shipped in Server 2022 circa mid 2021 (and is used as the implementation backend by MsQuic on Server 2022 and W11).
Imagine your team does not want to write a test because it's too much work or hard to model - this is a great example to bring up.
What is a CCA in this context?
There was the proposed eTLA namespace extension...
https://www.catb.org/jargon/html/T/TLA.html
After the initial packet loss triggered purposefully the first two seconds in this experiment, the only thing which could cause loss is the network queue (i.e. a simple tail drop, fq-codel, etc) which cannot process packets faster than they can arrive. At this point the link is saturated. The loss becomes a signal for CUBIC to reduce its window. This causes the oscillations you pointed out.
Unlike CUBIC, BBR [0] uses a model-based approach that estimates the available bandwidth and leaves some headroom kind of like you suggest to achieve higher throughput, and doesn't react as aggressively to loss as CUBIC.
[0] https://datatracker.ietf.org/meeting/104/materials/slides-10...
Most control loops have the same property. The path the system follows 99% of the time gets well-exercised; the path it falls into when things go wrong is the path you actually need to be correct on. There's usually no way to discover the bug until you deliberately drive the system into the bad regime and watch it try to climb out.
May not be related, but it might. It only recently started happening to me/our sites in the past couple of days.
I don't understand where or how AI picked up that habit, because it's self evidently terrible. It makes it clear how low signal AI based writing is. The writing is like the music in shitty blockbusters; engineered to make you feel, rather than to actually structure the content or provide meaningful sections.
Compare this writeup to the Pixter writeup, where sections feel natural and not "scripted" like this.
The LLM pass (unsurprisingly) made it worse.
For example:
The results were conclusive: 100% pass rate, showing Reno recovered cleanly after the loss phase, and revealing that this is a CUBIC-related bug.
Look, I’m reading a description of a Linux kernel network congestion bug. I don’t need the hand-holding.
So instead of:
> President Jackson said "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.".
They'll do something like:
> President Jackson noted that "Lorem ipsum dolor sit amet". The head of state also remarked that "consectetur adipiscing elit" while emphasizing that "sed do eiusmod tempor incididunt ut labore et dolore magna aliqua".
> "Ut enim ad minim veniam, quis nostrud exercitation", categorically proclaimed the former business tycoon. He concluded that "ullamco laboris nisi ut aliquip ex ea commodo consequat".
I've seen this way before LLMs and how much it's used varies a bit from language to language. But it's so formulaic, I can't help but imagine some brain-dead moron sitting in front of the keyboard, trying to make 5 paragraphs from 2 sentences someone said without adding anything else.
I wonder what happened with the very hardcore engineering that used to happen at Cloudflare and was published? Almost every blog post today seems to expose some weirdness at Cloudflare, rather than highlighting excellence in engineering, what changes? Been slowly changing over the years, did they change their hiring practices or something?