$cat /proc/sys/net/ipv4/tcp_frto 2 $
Enables Forward RTO-Recovery (F-RTO) defined in RFC4138. F-RTO is an enhanced recovery algorithm for TCP retransmission timeouts. It is particularly beneficial in wireless environments where packet loss is typically due to random radio interference rather than intermediate router congestion. F-RTO is sender-side only modification. Therefore it does not require any support from the peer. If set to 1, basic version is enabled. 2 enables SACK enhanced F-RTO if flow uses SACK. The basic version can be used also when SACK is in use though scenario(s) with it exists where F-RTO interacts badly with the packet counting of the SACK enabled TCP flow. source: linux kernel documentation.
Existing loss recovery techniques are not effective in dealing with packet losses and new techniques must be developed to handle them. Almost 50% of all losses required a coarse timeout to recover. Fast retransmissions recovered from less than 45% of all losses. The remainder of losses were during slow start following a timeout. Future network implementations should increase their default socket buffer size to avoid the receiver window from becoming a bottleneck. The socket buffer size limited the throughput of approximately 14% of all observed connections. A client using a collection of parallel connections between a client and server is a more aggressive user of the network than an application that uses a single TCP connection. Throughput is positively correlated with the number of active connections. When multiple connections are concurrently active and one of them experiences a loss, only half of the remaining ones on average experience a loss. The combined congestion window of a group of parallel connections does not decrease as much as the congestion window of a single connection after a loss epoch. Of a group of parallel connections, ones with small outstanding windows could experience a larger number of losses than their share of the total outstanding window would warrant. This means that it may be harder to initiate a new connection than to keep an existing connection going. source : TCP Behavior of a Busy Internet Server: Analysis and Improvements Hari Balakrishnan*, Venkata N. Padmanabhan*, Srinivasan Seshan+, Mark Stemm*, Randy H. Katz*
code fragments. /* Abort F-RTO algorithm if one is in progress */ tp->frto_counter = 0; /* Do not perform any recovery during F-RTO algorithm */ if (tp->frto_counter) return 0; /* F-RTO spurious RTO detection algorithm (RFC4138) * * F-RTO affects during two new ACKs following RTO (well, almost, see inline * comments). State (ACK number) is kept in frto_counter. When ACK advances * window (but not to or beyond highest sequence sent before RTO): * On First ACK, send two new segments out. * On Second ACK, RTO was likely spurious. Do spurious response (response * algorithm is not part of the F-RTO detection algorithm * given in RFC4138 but can be selected separately). * Otherwise (basically on duplicate ACK), RTO was (likely) caused by a loss * and TCP falls back to conventional RTO recovery. F-RTO allows overriding * of Nagle, this is done using frto_counter states 2 and 3, when a new data * segment of any size sent during F-RTO, state 2 is upgraded to 3. * * Rationale: if the RTO was spurious, new ACKs should arrive from the * original window even after we transmit two new data segments. * * SACK version: * on first step, wait until first cumulative ACK arrives, then move to * the second step. In second step, the next ACK decides. * * F-RTO is implemented (mainly) in four functions: * - tcp_use_frto() is used to determine if TCP is can use F-RTO * - tcp_enter_frto() prepares TCP state on RTO if F-RTO is used, it is * called when tcp_use_frto() showed green light * - tcp_process_frto() handles incoming ACKs during F-RTO algorithm * - tcp_enter_frto_loss() is called if there is not enough evidence * to prove that the RTO is indeed spurious. It transfers the control * from F-RTO to the conventional RTO recovery */ source: linux kernel sources. tcp_input.c