Live data from Hacker News

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

github.com

61–70 of 87 posts

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

#61
post #60

Earlier quoted context omitted.

It's interesting how long we've been waiting for fair queuing to fix congestion problems in the Internet. The first proper research on this was published in 1989: https://dl.acm.org/doi/10.1145/75246.75248 I'm a big fan of fair queuing, and have it enabled for my home network. But in core routers, the best approximation is likely to be WFQ, where you're likely to have each flow hashed to one of something like 256 que…

Fair queuing would be extremely difficult to support while maintaining overall peak performance. Way too much shared state.

I can think of ways to approximate FQ on an input-queued switch while maintaining performance, but it doesn't really help because the total number of queues being a function of the traffic still opens you up to resource exhaustion attacks.

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

#62

> Unlike BBR, Brutal operates on a fixed rate model and does not reduce its speed in response to packet loss or RTT changes. [...] It's particularly effective at seizing bandwidth in congested, best-effort delivery networks, hence its name. So if there's one TCP flow using Brutal, all other traffic gets pushed out. Fair queuing can prevent this. If one can be sure that there's fair queuing, one can do much smoother c…

It's interesting how long we've been waiting for fair queuing to fix congestion problems in the Internet. The first proper research on this was published in 1989: https://dl.acm.org/doi/10.1145/75246.75248 I'm a big fan of fair queuing, and have it enabled for my home network. But in core routers, the best approximation is likely to be WFQ, where you're likely to have each flow hashed to one of something like 256 que…

[deleted]

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

#63
I'm surprised that this got posted on Hacker News and got enough attention. It was designed mostly for China's special situation.

China only has a handful nodes for connecting to the rest of the world. Each of the node is conceptually a single router handling billions of connections. The conventional model of congestion control algorithm breaks down:

1. The exit nodes are always under congestion. By conventional wisdom of congestion control, we should reduce our speed to wait until the congestion is resolved. That is, to reduce speed to 0 and wait until infinity.

2. The exit nodes cannot do real time traffic shaping of individual connections due to the sheer amount of them. As a result, the packet loss and RTT changes are mostly random noise. Basing the send rate on random noise does not make sense.

3. Even if one connection halves its rate, it only improves the situation by less than 0.000000001%.

4. If I sustain a high speed (300 Mbps) for several hours, my connection to the same server will be throttled heavily for at least a week. So the exit nodes probably have an offline batch job picking out outliers and put them in a naughty list.

So the only thing that matters to an end user like me is to stay below the naughty threshold. Beyond that, dynamically adjusting the send rate on packet loss or RTT is mostly behavioral art.

Per my own experiment, keeping around 90 Mbps for long will not trigger the punishment of the exit node (or my ISP). Meanwhile, BBR gives only about 45 Mbps, and Cubic 15 Mbps (barely usable).

This is all assuming that the exit nodes are the bottleneck. When other parts of the network can be the bottleneck too, such as a crowded restaurant WiFi, I switch to BBR for the congestion control.

In addition, rest assured that Brutal will not see widespread adoption. In most cases, the sever does not know the bandwidth of the client, and cannot or will not trust the bandwidth data sent from the client. It's only in the special case where both the server and client are controlled by the same person where Brutal can be applied.

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

#64
I live in China. And I have to admit the global internet connection is very busy and limited here. But I don't think you are right. Filling the wire forcefully with retransmitted packets is a very bad behavior. It's not surprising to get blocked temporarily by your ISP.

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

#65
post #64

I live in China. And I have to admit the global internet connection is very busy and limited here. But I don't think you are right. Filling the wire forcefully with retransmitted packets is a very bad behavior. It's not surprising to get blocked temporarily by your ISP.

I remember the best internet connection was my own cellphone using roaming (Three), which seemed to bypass all the China bullshit.

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

#66

I'm surprised that this got posted on Hacker News and got enough attention. It was designed mostly for China's special situation. China only has a handful nodes for connecting to the rest of the world. Each of the node is conceptually a single router handling billions of connections. The conventional model of congestion control algorithm breaks down: 1. The exit nodes are always under congestion. By conventional wisd…

It's curious that you say RTT is mostly random noise yet BBR gives you only 45 Mbps. The whole idea of BBR is that it probes bandwidth vs RTT and finds the point at which RTT starts to increase.

Maybe BBR is just misbehaving due to too much noise? Wouldn't a better approach be to tweak BBR to spend more time probing or change the model parameters that it uses to estimate link bandwidth?

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

#67
post #4
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…

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

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

#68
post #28

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

You could check if you have SACKs [1] enabled - these can help by a lot on lossy uplinks using tcp.

[1] https://packetlife.net/blog/2010/jun/17/tcp-selective-acknow...

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

#69

I'm surprised that this got posted on Hacker News and got enough attention. It was designed mostly for China's special situation. China only has a handful nodes for connecting to the rest of the world. Each of the node is conceptually a single router handling billions of connections. The conventional model of congestion control algorithm breaks down: 1. The exit nodes are always under congestion. By conventional wisd…

> I'm surprised that this got posted on Hacker News and got enough attention.

> Proceeds to post a lot of interesting commentary.

Well, there you have it :P that’s why it gets posted and upvoted and commented on, because it is interesting to HN readers :D

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

#70
post #52

Earlier quoted context omitted.

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.

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

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