3 ms·
When latency decreased with faster connections but in an environment with packet loss, a new problem emerged: TCP incast collapse. There was plenty of available
by 1letterunixname 3y ago
When latency decreased with faster connections but in an environment with packet loss, a new problem emerged: TCP incast collapse. There was plenty of available bandwidth but TCP transfers would slow down, sometimes to a crawl, without QoS, packet shaping, or bandwidth limitations.
Mitigations include high resolution retransmit timers (RTO) and FQCN.
Didn't help: SACK, TCP Reno, and New Reno.
https://dl.acm.org/doi/10.1145/1592681.1592693 https://dl.acm.org/doi/10.1145/1592681.1592693
https://dl.acm.org/doi/pdf/10.1145/1592681.1592693 https://dl.acm.org/doi/pdf/10.1145/1592681.1592693
- ikekkdcjkfke 3y agoWhy would something drop packets?
- sambazi 3y agoare you talking about [0]? [0] https://en.wikipedia.org/wiki/TCP_global_synchronization https://en.wikipedia.org/wiki/TCP_global_synchronization
- dtaht 3y agoHere is a realworld example, easily duplicated by anyone with a big fifo AND enough flows, that happens all the time, with cubic: https://blog.cerowrt.org/post/juniper/ https://blog.cerowrt.org/post/juniper/
- the8472 3y agoThese are probably outdated. A lot has changed in TCP stacks since 2009.