[mhandley]

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.

[lq0000]

> 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?

[NeverBehave]

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.

[rfoo]

> but I wonder if the bandwidth profile of Hysteria compromises its HTTP/3 masquerade?

Most likely so. GFW is not able to reassemble and analyze QUIC (and AFAIK, any UDP-based multiplexed protocol) traffic, yet. If Hysteria takes off, GFW will try to kill it and so far it's likely to be degraded severely just as Shadowsocks, V2Ray or (ironically) Trojan.

Very few "censorship-resistance" proxy implementations out of China were designed to systematically evade traffic analysis, they usually just avoid general techniques and rely on being niche enough to fly under radar. Which is not wrong: being diverse is also a good strategy.

[_flux]

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.

[rft]

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.

[don-code]

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.

[ale42]

Except that Ghost was using (or still uses? I switched to udpcast since ages) ACKs from the destination hosts to adapt the bandwidth dynamically. So you didn't have to give/impose the bandwidth. The funny part was when a machine in a room with 45 PCs was misbehaving (read: failing HD), basically bringing the transfer rate close to zero for the whole deployment... and good luck finding out which machine it was.

[EvanAnderson]

Exactly my experience w/ Ghost, too. I moved over to udpcast as well. (The last time I did this kind of work I simply ended up blasting the output of "ntfsclone" via udpcast. I was very happy w/ how it worked.)

[ale42]

Am almost doing the same, basically udpcasting a file that was created with partclone.ntfs -c, and piping that to partclone.ntfs -r :)

[phyzome]

Sounds very torrent-y.

[wbl]

Fountain codes would be another choice for that application

[neilalexander]

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.

[mhandley]

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.

[dtaht]

We are making significant progress with CAKE & fq_codel in the WISP & and fiber markets as a middlebox. See Preseem, Bequant, and LibreQos.io. Still best to get these native on the CPE as Mikrotik and many many others have one.

I wonder how well these would work on the GFW?