Live data from Hacker News

TCP-brutal: Congestion control algorithm that increase speed on packet lost

github.com

1–10 of 87 posts

Re: TCP-brutal: Congestion control algorithm that increase speed on packet lost

#2
The Internet only works because TCP (and QUIC) congestion control does a reasonable job of matching offered load to available capacity. Without congestion control, the network is apt to get into congestion collapse, where the network is increasingly busy but getting no useful work done. We saw such congestion collapses in the 1980s. Van Jacobson's TCP congestion control algorithm was the response and its descendents have kept the Internet working ever since.

Now, in certain limited domains something like Brutal can work, but you really wouldn't want everyone to do it.

Re: TCP-brutal: Congestion control algorithm that increase speed on packet lost

#4
post #2

The Internet only works because TCP (and QUIC) congestion control does a reasonable job of matching offered load to available capacity. Without congestion control, the network is apt to get into congestion collapse, where the network is increasingly busy but getting no useful work done. We saw such congestion collapses in the 1980s. Van Jacobson's TCP congestion control algorithm was the response and its descendents…

> Like Hysteria, Brutal is designed for environments where the user knows the bandwidth of their connection, as this information is essential for Brutal to work.

They don't quite say that this is a bad idea for use over WAN. If they intentionally avoided ruling out such usage in this qualification, they're making an implicit assumption here that either the last-mile connection or the endpoints themselves are going to be the bottleneck. If some router in between is having a bad day, it would definitely make its day worse.

edit: I wasn't familiar with Hysteria but now that I'm reading those docs, I guess the intent is for this to be used on the internet. In that case, it does seem pretty like it'd be pretty adversarial to run this. I bet if it saw widespread adoption it'd make ISPs pretty upset.

edit 2: Going slightly off-topic now, but I wonder if the bandwidth profile of Hysteria compromises its HTTP/3 masquerade?

Re: TCP-brutal: Congestion control algorithm that increase speed on packet lost

#6
> It's particularly effective at seizing bandwidth in congested, best-effort delivery networks, hence its name.

So basically it's an algorithm designed to push out people who play nice?

This seems like an absolutely terrible idea. It seems like in terms of congestion control algorithms, the Internet has been balancing in the good quadrant of the Prisoner's Dilemma, probably mostly because the people who work on that low of a level are nerds with a functioning moral compass. Is that era coming to an end?

Re: TCP-brutal: Congestion control algorithm that increase speed on packet lost

#7
post #2

The Internet only works because TCP (and QUIC) congestion control does a reasonable job of matching offered load to available capacity. Without congestion control, the network is apt to get into congestion collapse, where the network is increasingly busy but getting no useful work done. We saw such congestion collapses in the 1980s. Van Jacobson's TCP congestion control algorithm was the response and its descendents…

I would think that more intelligent packet scheduling (like fair queuing) is also playing a significant role these days, with routers on the path being empowered to drop packets from one flow in order to service another. That helps to bully most TCP congestion control algorithms into throttling back to a fairer pace, as they'll just end up with lots of retries otherwise.

Re: TCP-brutal: Congestion control algorithm that increase speed on packet lost

#8
post #6

> It's particularly effective at seizing bandwidth in congested, best-effort delivery networks, hence its name. So basically it's an algorithm designed to push out people who play nice? This seems like an absolutely terrible idea. It seems like in terms of congestion control algorithms, the Internet has been balancing in the good quadrant of the Prisoner's Dilemma, probably mostly because the people who work on that…

True, it's a pretty dumb idea

On consumer networks at least, there is normally a queue scheduling stage where customers are weighted equally. So this would just sieze bandwidth from other connections from the same household. I think a similar thing usually happens on hosting platforms etc

Re: TCP-brutal: Congestion control algorithm that increase speed on packet lost

#9
post #2

The Internet only works because TCP (and QUIC) congestion control does a reasonable job of matching offered load to available capacity. Without congestion control, the network is apt to get into congestion collapse, where the network is increasingly busy but getting no useful work done. We saw such congestion collapses in the 1980s. Van Jacobson's TCP congestion control algorithm was the response and its descendents…

A long time ago I had a bad cable internet connection (high packet loss), but I also had good shell access to Uni's computers, so what I did was that I downloaded large files there and then I had encountered a tool that would be given three parameters:

- Destination IP and port

- Bytes per second

- Files to transfer

On the receiving end there was the counterpart.

The tool would send the data from the beginning to the end with given BPS and then start again from the beginning, skipping frames that it had received acknowledgements for, until all frames were acked.

Worked great! I was able to just select a bitrate that worked well and let it churn.

I don't remember the name of the tool, but I doubt there would be many use cases for it today—nor would it be very difficult to reimplement, given its brutal nature.

Re: TCP-brutal: Congestion control algorithm that increase speed on packet lost

#10
post #3

I remember as an undergrad thinking it was crazy that a lot of congestion control is essentially left up to the client to play nice.

It's because everyone knows what would happen if they didn't. If you deploy this kind of algorithm at scale, multiple clients fail to back off which only causes the router to drop both of their packets. Then they have to retransmit them instead of transmitting them to begin with at a rate that causes them to not be dropped, which is actually slower.
Post reply on HN