Merge branch 'tcp_stretch_acks'
Neal Cardwell says: ==================== fix stretch ACK bugs in TCP CUBIC and Reno This patch series fixes the TCP CUBIC and Reno congestion control modules to properly handle stretch ACKs in their respective additive increase modes, and in the transitions from slow start to additive increase. This finishes the project started by commit 9f9843a7 ("tcp: properly handle stretch acks in slow start"), which fixed behavior for TCP congestion control when handling stretch ACKs in slow start mode. Motivation: In the Jan 2015 netdev thread 'BW regression after "tcp: refine TSO autosizing"', Eyal Perry documented a regression that Eric Dumazet determined was caused by improper handling of TCP stretch ACKs. Background: LRO, GRO, delayed ACKs, and middleboxes can cause "stretch ACKs" that cover more than the RFC-specified maximum of 2 packets. These stretch ACKs can cause serious performance shortfalls in common congestion control algorithms, like Reno and CUBIC, which were designed and tuned years ago with receiver hosts that were not using LRO or GRO, and were instead ACKing every other packet. Testing: at Google we have been using this approach for handling stretch ACKs for CUBIC datacenter and Internet traffic for several years, with good results. v2: * fixed return type of tcp_slow_start() to be u32 instead of int ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Showing
Please register or sign in to comment