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

71–80 of 87 posts

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

#71

Post by bdd8f1df777b »

dkbrk wrote: post #66
bdd8f1df777b wrote: post #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 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?

Your idea does make sense. I'll try to see if I can tweak the BBR parameters on my server and achieve better performance.

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

#72

Post by FeepingCreature »

JohnBooty wrote: post #49
FeepingCreature wrote: post #35

Earlier quoted context omitted.

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…

If people download the complete file eventually, it should average out. And if people view half the file and then drop out, then the earlier chunks being more available is optimal.

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

#73

Post by BillFranklin »

twic wrote: post #56
BillFranklin wrote: post #5

If you're interested in recent state-of-art improvements to TCP congestion control, check out the Remy project, it's pretty amazing https://web.mit.edu/remy/ .

> But there is a closely-related question, which is to ask: how much does Remy depend on the way the simulator works? Will it work on real networks? We have some confidence that the results don't depend on fine details of the simulator, because RemyCCs are optimized within Remy's own simulator but evaluated inside ns-2 and its TCP implementations, which were developed independently and long predate Remy. But the only…

I’m not sure if much more research has been done here from this team. I was able to produce similar results in my dissertation, also not in a production setting.

Regarding your second point, the way congestion avoidance algorithms typically work is to punish the local client for the state of the global congestion. If Remy can do that in a more efficient way (ie greater throughput or fairness for the local client) then it would be beneficial to use the algorithm before others switch.

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

#74

Post by champtar »

BillFranklin wrote: post #5

If you're interested in recent state-of-art improvements to TCP congestion control, check out the Remy project, it's pretty amazing https://web.mit.edu/remy/ .

The page mentions Ubuntu 13.04 and doesn't mention BBR, is the project still active ?

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

#75

Post by muxamilian »

mhandley wrote: post #61
xxpor wrote: post #60

Earlier quoted context omitted.

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.

Fair queuing shouldn't be necessary in the core. If every base station/WiFi router/client device support fair queuing that should be enough.

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

#76

Post by JohnBooty »

FeepingCreature wrote: post #72
JohnBooty wrote: post #49

Earlier quoted context omitted.

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…

If people download the complete file eventually, it should average out. And if people view half the file and then drop out, then the earlier chunks being more available is optimal.

    If people download the complete file eventually, it should average out
Yes. As supply of the rarer chunks increases, the problems go away.

Notice the implicit fact up there. The uneven distribution of chunks causes problems.

    then the earlier chunks being more available is optimal.
For most use cases, no, the first chunks of the file are not more valuable. Having the first 99 chunks of a Linux .ISO is not valuable at all if you don't have the 100th chunk. The chunks are equally valuable and the chunks are useless unless you have them all.

There are some (or were?) torrent clients that let you start watching incomplete downloads while they're still downloading. This is a dubious use case. I do not notice many people using these nonstandard clients.

Also even for some kind of livestreaming scenario, what are even the "first" chunks? The start of the stream? The stream at the current time? It's probably a moot point anyway because it seems like Bittorrent livestreaming hasn't exactly taken the world by storm but maybe there are uses of it with which I'm not familiar: https://www.google.com/search?client=firefox-b-1-d&q=bittorr...

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

#77

Post by pests »

codetrotter wrote: post #69
bdd8f1df777b wrote: post #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 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

Yeah, similar thoughts.

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

#78

Post by rfoo »

dkbrk wrote: post #66
bdd8f1df777b wrote: post #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 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?

> It's curious that you say RTT is mostly random noise yet BBR gives you only 45 Mbps.

I believe OP meant RTT fluctuate somewhere between 150ms to 250ms completely randomly even with no load at all, hence (the delta is) mostly random noice. Not that the RTT is below 0.1ms and barely measurable.

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

#79

Post by FeepingCreature »

JohnBooty wrote: post #76
FeepingCreature wrote: post #72

Earlier quoted context omitted.

If people download the complete file eventually, it should average out. And if people view half the file and then drop out, then the earlier chunks being more available is optimal.

If people download the complete file eventually, it should average out Yes. As supply of the rarer chunks increases, the problems go away. Notice the implicit fact up there. The uneven distribution of chunks causes problems. then the earlier chunks being more available is optimal. For most use cases, no, the first chunks of the file are not more valuable. Having the first 99 chunks of a Linux .ISO is not valuable at…

> For most use cases, no, the first chunks of the file are not more valuable. Having the first 99 chunks of a Linux .ISO is not valuable at all if you don't have the 100th chunk.

Sure but we just established that people are dropping out in mid-watch. For most use cases, people aren't interested in downloading the first chunks first; those cases where they are, and where it doesn't eventually average out, are exactly the cases where the earlier chunks are more important.

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

#80

Post by dtaht »

mhandley wrote: post #11
neilalexander wrote: post #7

Earlier quoted context omitted.

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.

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…

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?

Post reply on HN