[bdd8f1df777b]

I'm surprised that this got posted on Hacker News and got enough attention. It was designed mostly for China's special situation.

China only has a handful nodes for connecting to the rest of the world. Each of the node is conceptually a single router handling billions of connections. The conventional model of congestion control algorithm breaks down:

1. The exit nodes are always under congestion. By conventional wisdom of congestion control, we should reduce our speed to wait until the congestion is resolved. That is, to reduce speed to 0 and wait until infinity.

2. The exit nodes cannot do real time traffic shaping of individual connections due to the sheer amount of them. As a result, the packet loss and RTT changes are mostly random noise. Basing the send rate on random noise does not make sense.

3. Even if one connection halves its rate, it only improves the situation by less than 0.000000001%.

4. If I sustain a high speed (300 Mbps) for several hours, my connection to the same server will be throttled heavily for at least a week. So the exit nodes probably have an offline batch job picking out outliers and put them in a naughty list.

So the only thing that matters to an end user like me is to stay below the naughty threshold. Beyond that, dynamically adjusting the send rate on packet loss or RTT is mostly behavioral art.

Per my own experiment, keeping around 90 Mbps for long will not trigger the punishment of the exit node (or my ISP). Meanwhile, BBR gives only about 45 Mbps, and Cubic 15 Mbps (barely usable).

This is all assuming that the exit nodes are the bottleneck. When other parts of the network can be the bottleneck too, such as a crowded restaurant WiFi, I switch to BBR for the congestion control.

In addition, rest assured that Brutal will not see widespread adoption. In most cases, the sever does not know the bandwidth of the client, and cannot or will not trust the bandwidth data sent from the client. It's only in the special case where both the server and client are controlled by the same person where Brutal can be applied.

[codetrotter]

> I'm surprised that this got posted on Hacker News and got enough attention.

> Proceeds to post a lot of interesting commentary.

Well, there you have it :P that’s why it gets posted and upvoted and commented on, because it is interesting to HN readers :D

[pests]

Yeah, similar thoughts.

[dkbrk]

It's curious that you say RTT is mostly random noise yet BBR gives you only 45 Mbps. The whole idea of BBR is that it probes bandwidth vs RTT and finds the point at which RTT starts to increase.

Maybe BBR is just misbehaving due to too much noise? Wouldn't a better approach be to tweak BBR to spend more time probing or change the model parameters that it uses to estimate link bandwidth?

[rfoo]

> It's curious that you say RTT is mostly random noise yet BBR gives you only 45 Mbps.

I believe OP meant RTT fluctuate somewhere between 150ms to 250ms completely randomly even with no load at all, hence (the delta is) mostly random noice. Not that the RTT is below 0.1ms and barely measurable.

[bdd8f1df777b]

Your idea does make sense. I'll try to see if I can tweak the BBR parameters on my server and achieve better performance.