$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
.png)