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.

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.

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/

>it should be able to do that job just fine even if you keep throwing lots of packets at it, right?

there's circumvention techniques that abuse the fact that they can't: https://upb-syssec.github.io/blog/2023/record-fragmentation

the intentionally terrible speeds are decided by software heuristics, so antisocial limits are fought with antisocial techniques, with continued brutality being enough to skip the slow deep packet inspection path via force

If that's actually the case, then using this congestion control algorithm for that purpose is okay I suppose.

it's your first scenario. the infrastructure is fine, but there's a middlebox in the way, doing whatever it can to fuck with your connection. the middlebox will drop packets. this middlebox will invent RST packets and spam them at you to make you think the connections been dropped. using the antisocial congestion control manages to get you more than 2Kbps with the middlebox still doing its thing.

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

You should see what products like Signiant do

What does Signiant do? And what does Signiant DO?

Uses UDP to aggressively use every drop of bandwidth to spray files in a way which makes brutal look like cubic

>"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.

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.

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.

The dataset here is 17 TB+, so HDD storage is the only thing that's economically viable, especially for a service hosted as a hobby. :-) It doesn't really help that they DoS themselves, they still do it.

(After I limited connections to one per IP address, 90% of the problems went away. After I started blackholing users ignoring 503 responses, the remaining 10% were solved. I get the occasional “I didn't knooow, please give me access again” email now and then.)