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

21–30 of 87 posts

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

#21

Post by don-code »

_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…

Norton Ghost could do something similar, but with UDP multicast. You'd boot a room full of machines to Ghost, have them join a multicast group, multicast an OS image to them, and then have the host machine just send the image out once (from its perspective), saving a ton of bandwidth in the process. The individual machines would then rerequest any chunks that they missed.

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

#22

Post by phyzome »

don-code wrote: post #21
_flux wrote: post #9

Earlier quoted context omitted.

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…

Norton Ghost could do something similar, but with UDP multicast. You'd boot a room full of machines to Ghost, have them join a multicast group, multicast an OS image to them, and then have the host machine just send the image out once (from its perspective), saving a ton of bandwidth in the process. The individual machines would then rerequest any chunks that they missed.

Sounds very torrent-y.

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

#23

Post by progbits »

kazinator wrote: post #16

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 t…

I don't think you even get faster transfers, at least beyond some short term gain. You will overload some router on the path and just increase packetloss for everyone without improving your goodput.

Maybe my intuition is wrong but there are no graphs and real world measurements.

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

#24

Post by Agingcoder »

joelthelion wrote: post #15
BillFranklin wrote: post #5

If you're interested in recent state-of-art improvements to TCP congestion control, check out the Remy project, it's pretty amazing https://web.mit.edu/remy/ .

Out of curiosity, what do modern OSes use?

Cubic, or bbr I’ve seen in practice. Bbr is extremely efficient in particular ( and I’d like to know how Rémy compares to it )

Edit: bbr essentially builds and fits a model - in some ways it’s learning ( it’s stats essentially).

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

#25

Post by hnav »

joelthelion wrote: post #15
BillFranklin wrote: post #5

If you're interested in recent state-of-art improvements to TCP congestion control, check out the Remy project, it's pretty amazing https://web.mit.edu/remy/ .

Out of curiosity, what do modern OSes use?

cubic and bbr

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

#26

Post by Sesse__ »

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…

There's already a variant of this from the receiver side, the so-called “download accelerators”. I've seen some of those literally open hundreds of connections for the same file until the server was full (hit its MaxServers limit), and when the server started sending 503 Too Busy, they would retry every 10 milliseconds. Several of them would mask their user agent. When I asked a user (unrelated to that specific program) about why they'd use something like this, their answer was “I've paid for 50 Mbit/sec, I will have 50 Mbit/sec”.

I can tell you, hosting files in such an environment and trying to work from the same machine is not a pleasant experience.

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

#27

Post by JohnBooty »

kazinator wrote: post #16

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 t…

Reminds me of those "alternative" bittorrent clients that did neat things by, basically, behaving in selfish ways.

The main example behavior I remember was that these clients would sort of cheat by downloading the file chunks in sequential order (so they could start playing the media sooner) rather than in random order (which is a big part of what makes bittorrent a pretty effective protocol/algorithm)

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

#28

Post by ta1243 »

progbits wrote: post #23
kazinator wrote: post #16

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 t…

I don't think you even get faster transfers, at least beyond some short term gain. You will overload some router on the path and just increase packetloss for everyone without improving your goodput. Maybe my intuition is wrong but there are no graphs and real world measurements.

In some cases you could. I had an issue last week with my 1G leased circuit with a 160ms rtt

That circuit had a 1% packet loss on it due to a dodgy SFP. This devastated cubic, with peak TCP transfer dropping from 150mbit (we police it to about that) to less than 1mbit. BBR was better but still down a fair bit.

Using this algorithm I presume it would have continued at about 140-150mbit.

I don't really do TCP so haven't looked too closely at different algorithms in different latency/loss (burst or constant) conditions, but I can see where this type of algorithm could be useful.

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

#29

Post by mort96 »

NeverBehave wrote: post #20
mort96 wrote: post #17

Earlier quoted context omitted.

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 th…

Okay, say it's part of the censorship, and parts of the Internet are intentionally "soft-blocked" in the way you describe.

If the degraded performance some kind of artificial throttling, then I have a hard time understanding how an antisocial congestion control algorithm would help. If there's some middle box tasked with providing every IP address no more than 2kbit/s, then it should be able to do that job just fine even if you keep throwing lots of packets at it, right?

If the degraded performance is simply due to intentionally terrible infrastructure and there's real congestion going on due to many Chinese people trying to access the Internet at the same time, then using an antisocial congestion control algorithm might give you faster transfers, at the cost of everyone else. If everyone started using these antisocial congestion control algorithms, the end result would simply be that nobody would get to communicate with those "soft-blocked" parts of the Internet, not even at those 2 kbit/s.

In short, I don't understand how this could even in principle be an effective tool for fighting censorship. I'm happy to reconsider if anyone describes such a use case in technical detail though.

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

#30

Post by fmajid »

JohnBooty wrote: post #27
kazinator wrote: post #16

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 t…

Reminds me of those "alternative" bittorrent clients that did neat things by, basically, behaving in selfish ways. The main example behavior I remember was that these clients would sort of cheat by downloading the file chunks in sequential order (so they could start playing the media sooner) rather than in random order (which is a big part of what makes bittorrent a pretty effective protocol/algorithm)

That's pretty much what Google is doing with QUIC and BBR, aka HTTP/3. Tragedy of the Commons in the making.
Post reply on HN