TCPTuner: Congestion Control Your Way
1–5 of 5 posts
Re: TCPTuner: Congestion Control Your Way
#2Sources on GitHub:
Re: TCPTuner: Congestion Control Your Way
#3Neat. It's disappointing how TCP congestion control is one of the main limiting factors of modern broadband connections. Even downloading from S3 or something it takes up to a minute before TCP discovers the link bandwidth, when the transfer could have been finished in seconds if it was more aggressive. There doesn't seem to be much practical development in the area either. Is congestion collapse still a concern in today's internet?
Re: TCPTuner: Congestion Control Your Way
#4This would be great for a simple classroom demo on congestion control!
Re: TCPTuner: Congestion Control Your Way
#5Neat. It's disappointing how TCP congestion control is one of the main limiting factors of modern broadband connections. Even downloading from S3 or something it takes up to a minute before TCP discovers the link bandwidth, when the transfer could have been finished in seconds if it was more aggressive. There doesn't seem to be much practical development in the area either. Is congestion collapse still a concern in t…
The problem isn't a lack of research, it's lack of deployment. OS vendors aren't turning on ECN and they largely aren't enabling their new congestion control algorithms by default. Slow-start of some kind is still absolutely required, because with an initial window of 10 packets a single new connection can swamp a 5Mbit or slower link for 24ms or more, and that occurs far too often in the real world to ignore. Interactive usability is more important than shaving a few seconds off bulk downloads.
If ECN and fair queuing were generally supported on the internet at large, then senders would get quicker feedback about congestion and the negative side effects of overly-aggressive senders would be greatly reduced. Even without deployment of those throughout the network, delay based congestion control at the endpoints helps, if the sender turns it on.