Live data from Hacker News

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

github.com

41–50 of 87 posts

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

#41
> 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 congestion control: https://github.com/muxamilian/fair-queuing-aware-congestion-...

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

#42
post #29

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…

>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

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

#43
post #36
post #33

Earlier quoted context omitted.

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

Thanks! That answers my question.

For anyone who doesn't feel like clicking on a PDF, the section title is "Rarest First".

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

#44
post #29

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…

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.

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

#45
post #28

Earlier quoted context omitted.

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

If many people are driving aggressively and cutting in, everyone is made late; but those who engage in the behavior arrive earlier than those who refrain.

A router that is dropping packets due to being congested is still forwarding some packets. If you wallop that router with your own packets, that's your best chance of getting more of your packets to be forwarded, at the expense of someone else's being dropped. (Assuming the router has no countermeasure against that behavior.)

If we take a simple leaky bucket model: the router drops the packet because it has no resources in that moment. A moment later, space opens up because of transmitted/cleared data, so when a packet is received in that later moment, is not dropped. There is likely a chain of leaky buckets: multiple points in the router traversal where packets can be dropped due to resource issues: dropping could be on the receive side or transmit. Wherever there is a queue whose length is capped or a memory allocation operation.

If you wallop that machine with your packets, you increase the chances that when those moments come when resources are available that allow a packet to be retained rather than leaked onto the floor, that opportunity goes to one of your packets rather than someone else's.

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

#46
post #29

Earlier quoted context omitted.

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…

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

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

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

#47
post #13

Earlier quoted context omitted.

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

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

#48

Earlier quoted context omitted.

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

If many people are driving aggressively and cutting in, everyone is made late; but those who engage in the behavior arrive earlier than those who refrain. A router that is dropping packets due to being congested is still forwarding some packets. If you wallop that router with your own packets, that's your best chance of getting more of your packets to be forwarded, at the expense of someone else's being dropped. (Ass…

That's only true if the router drops randomly rather than hashing into buckets by host

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

#49

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

Bittorrent does livestreams? Did not know that.

But for "normal" Bittorrent usage, oh hell naaaaah.

Where you are trying to actually obtain a complete file, that can be a disaster. What happens is the chunks at the end of the file will be much rarer than the chunks at the beginning. Getting the blocks sequentially offers a small convenience benefit (you can start viewing a video while the torrent is still downloading) but if significant numbers of people did that it would harm every other use case including your own ability to actually download the entire file.

If you have a surplus of seeders this isn't a problem, but for sparsely-seeded torrents that is not good.

Post reply on HN