Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

11–20 of 87 posts

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

#11

Post by mhandley »

neilalexander wrote: post #7
mhandley wrote: 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.

At the edge, if Brutal comes up against FQ-Codel or Cake in your (recent) Linux router, then if it causes congestion it should shoot itself in the foot, and other traffic shouldn't see too much adverse impact. When Brutal is limited to its fair share and sees loss, it will likely increase, get more loss, and only cause itself pain. Unfortunately Cake isn't all that widespread yet in home routers.

In large routers at ISPs, the best tool that is likely to be available is WFQ, with a limited number of hash buckets available. Likely WFQ will bundle many other flows together in the same bucket with a Brutal flow, so Brutal will still cause collareral damage if it encounters congestion.

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

#12

Post by NeverBehave »

lq0000 wrote: post #4
mhandley wrote: 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…

It is intentionally used on WAN. Brutal part of Hysteria(https://news.ycombinator.com/item?id=38026756) internal components, and Hysteria is a proxy made for people in China under censorship, where outbound Internet access is heavily degraded.

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

#13

Post by ta1243 »

mort96 wrote: 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…

You should see what products like Signiant do

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

#14

Post by elitepleb »

mort96 wrote: 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…

it's main use is in censorship resistant proxies, where the network at large does not have a good quadrant.

https://hysteria.network/

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

#16

Post by kazinator »

Car-brutal: new congestion control algorithm!

Pass everyone fast in the left lane, get to within 50 yards of the target exit (where they are are all also going) and then hit your brakes to cut back in, sending a peristaltic wave of stoppage backward in the fast lane.

In networking, packets can disappear due to hardware (mainly on wireless) or due to being deliberately dropped due to congestion. You can't tell these two scenarios apart. It makes sense to try harder in the former scenario, but trying harder in the latter scenario makes the congestion worse for the entire network, while eking out a minor improvement for that connection. If every node does it, the entire network will be far worse off, so it is counterproductive.

TCP congestion control depends on cooperation: that every node complies with the RFC requirements to implement all the necessary algorithms. That unfortunately leaves room for idiots and dickheads, hence from time to time we may see work like this. "Hey, if I blatantly break the RFC, I get faster transfers. Holy shit, how come nobody knows about this?"

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

#17

Post by mort96 »

elitepleb wrote: post #14
mort96 wrote: 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…

it's main use is in censorship resistant proxies, where the network at large does not have a good quadrant. https://hysteria.network/

I don't understand the connection between censorship and congestion control. Surely there's a good quadrant where everyone plays nice in terms of congestion control, even though there are bad actors doing censorship in other ways? Surely censorship isn't generally performed by making the network artificially congested so that you may access the censored material but a bit more slowly?

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

#18

Post by giardini »

mort96 wrote: 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…

>"So basically it's an algorithm designed to push out people who play nice?"Perhaps should be renamed TCP-Peking in contrast to TCP-HongKong where queuing is accepted behavior.

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

#19

Post by wbl »

_flux wrote: post #9
mhandley wrote: 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…

Fountain codes would be another choice for that application

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

#20

Post by NeverBehave »

mort96 wrote: post #17
elitepleb wrote: post #14

Earlier quoted context omitted.

it's main use is in censorship resistant proxies, where the network at large does not have a good quadrant. https://hysteria.network/

I don't understand the connection between censorship and congestion control. Surely there's a good quadrant where everyone plays nice in terms of congestion control , even though there are bad actors doing censorship in other ways? Surely censorship isn't generally performed by making the network artificially congested so that you may access the censored material but a bit more slowly?

That's actually part of the situation in China --- degraded network situation to certain part of the Internet. You may be able to establish connections e.g. Github, and even okay to download release from S3, but usually speed is stable around 2-3kb/s, which is effectively useless.

I am not certain this is due to the censorship, but this issue is sitting there for at least a decade.

Big Corps in China usually setup their own VPN/Private Line to workaround this situation.

Post reply on HN