4 ms·
TCP would really suck if it went to multi-second coma on every bandwidth adjustment! Buffer getting "overwhelmed" is exactly what causes TCP to adjust. Fortun
by zurn 13y ago
TCP would really suck if it went to multi-second coma on every bandwidth adjustment!
Buffer getting "overwhelmed" is exactly what causes TCP to adjust.
Fortunately TCP doesn't go to slow start immediately when it sees congestion in the network.
It first tries slowing down. There's a "congestion avoidance" phase as long as not too many packets are lost, "slow start" happens only when congestion avoidance gives up.
Excess buffering can infact mess up congestion avoidance in addition to causing needless additional latency, since it in effect postpones the timely signaling of link capacity. See the bits about congestion control at https://www.bufferbloat.net/projects/bloat/wiki/TechnicalIntro https://www.bufferbloat.net/projects/bloat/wiki/TechnicalInt...
After this probing initially happens, TCP will remember the link bandwidth, window size etc even after periods of inactivity.
This is also how UDP based protocols are expected to behave (specced by IETF/IAB).
- JoeAltmaier 13y agoAll cool if you have one connection and don't share it. But real apps on real computers have multiple apps running - while you're trying to communicate, email fires up and scans a dozen servers; your progeny upstairs clicks on a video; ROKU decides to update. Bandwidth and window size are a fiction over time. TCP believes they will be stable (for many seconds); its tuned for old server-to-server connections, not the extremely dynamic network conditions in the average home/business today. So you end up in slow start and congestion avoidance, and only after packets are dropped and resent pointlessly adding to congestion (as you point out). I've spent years now examining traces of TCP catastrophes. It's because TCP is NOT dynamic enough that folks like my company are driven to finding alternatives. So yes TCP really sucks. For many applications.