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

31–40 of 87 posts

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

#31

Post by progbits »

ta1243 wrote: post #28
progbits wrote: post #23

Earlier quoted context omitted.

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

OK I suppose that is what GP meant with the first category - if there is no congestion but your physical layer is dodgy this can indeed help.

But if many people start using it this will fail on congestion (and even if there is little congestion to begin with, this will amplify it so there is sure to be some).

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

#32

Post by rft »

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

About 2 years ago I had a similarly bad cable connection. I could push nearly 500mbit/s UDP through it, as advertised, but HTTPS downloads and TCP streams would only reach about 80mbit/s each. I could run multiple of them in parallel to max out the downstream on TCP alone. I also tracked it down to a low packet loss on the connection that caused TCP to reduce its rate.

I wondered whether you could add a VPN-like layer that retransmits and potentially reorders TCP packets itself without letting the actual endpoint TCP stack handle it. That way it should transparently remove the packet loss at the cost of additional complexity and higher latency.

I wish I knew about Hysteria, but I never made the connection to censored networks. It seems like it could be (ab)used for this use case.

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

#33

Post by nix0n »

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)

If multiple users download in sequential order, wouldn't that actually make it pretty likely that the previous downloader would have the chunk that the next downloader is looking for?

Or is there a specific advantage to random order?

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

#34

Post by MadnessASAP »

ta1243 wrote: post #13
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

What does Signiant do? And what does Signiant DO?

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

#35

Post by FeepingCreature »

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)

If lots of people are watching the file sequentially, then sequential order is close to optimal. Consider a Bittorrent-based lifestream. Clients should focus on getting and distributing the chunks that everyone wants.

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

#36

Post by the8472 »

nix0n wrote: post #33
JohnBooty wrote: post #27

Earlier quoted context omitted.

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)

If multiple users download in sequential order, wouldn't that actually make it pretty likely that the previous downloader would have the chunk that the next downloader is looking for? Or is there a specific advantage to random order?

see http://bittorrent.org/bittorrentecon.pdf section 2.4.2

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

#37

Post by TonyTrapp »

nix0n wrote: post #33
JohnBooty wrote: post #27

Earlier quoted context omitted.

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)

If multiple users download in sequential order, wouldn't that actually make it pretty likely that the previous downloader would have the chunk that the next downloader is looking for? Or is there a specific advantage to random order?

With clients constantly appearing and disappearing, the probability that you will be able to finish the download will be much higher if everyone has a random collection of file parts. Imagine the original seeder goes away after one day. Everyone is stuck at 99% because they downloaded in sequential order. Nobody has the last missing part. This would be much less likely if the clients had downloaded random parts instead, because every part would be roughly equally likely to be available in the end.

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

#38

Post by muxamilian »

sam0x17 wrote: 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 sounds crazy but fortunately fair queuing is becoming more and more prevalent, making sure everyone plays nice. Every iPhone has it: https://blog.cerowrt.org/post/state_of_fq_codel/

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

#39

Post by phh »

Sesse__ wrote: post #26
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 progr…

Funny thing is, I used to (and still sometime do) host on a webserver with HDD storage. The users using such downloaders were DoSing themselves and got less than a tenth of a sequential download.

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

#40

Post by NeverBehave »

mort96 wrote: post #29
NeverBehave wrote: post #20

Earlier quoted context omitted.

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…

Here is the opinion from the author, unfortunately it only has Chinese version but here is the relevant part translated using deepl:

> And if you insist on sending packets, even though the other traffic does not give way, since your packets are taken more proportion of the traffic, they would more likely to be selected. Whether it's "ethical" to "grab" bandwidth in this way is a subjective question, but the objective root cause is the urgent need to expand the operator's equipment with insufficient bandwidth. Operators should not expect users to be "sympathetic" to the lack of backbone capacity - the operator has contracted a rate with the user and the user is not cracking that limit, just using the bandwidth that the operator has committed to them, which is reasonable behavior.

Personally I don't think it is a good idea, but I was in that situation during my high school, and it was terrible. I get the idea why this project would exist sooner or later and just trying to present some context for discussion.

https://v2.hysteria.network/zh/docs/misc/Hysteria-Brutal/

Post reply on HN