aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/networking
diff options
context:
space:
mode:
authorYuchung Cheng <ycheng@google.com>2013-03-20 09:33:00 -0400
committerDavid S. Miller <davem@davemloft.net>2013-03-21 11:47:51 -0400
commite33099f96d99c391b3325caa9c44258de04aae86 (patch)
tree715791ad4d04ba8fe3b1063187d80ea4d1e82afe /Documentation/networking
parentab42d9ee3d215ab74a49818ffc53771a88ce7ddf (diff)
tcp: implement RFC5682 F-RTO
This patch implements F-RTO (foward RTO recovery): When the first retransmission after timeout is acknowledged, F-RTO sends new data instead of old data. If the next ACK acknowledges some never-retransmitted data, then the timeout was spurious and the congestion state is reverted. Otherwise if the next ACK selectively acknowledges the new data, then the timeout was genuine and the loss recovery continues. This idea applies to recurring timeouts as well. While F-RTO sends different data during timeout recovery, it does not (and should not) change the congestion control. The implementaion follows the three steps of SACK enhanced algorithm (section 3) in RFC5682. Step 1 is in tcp_enter_loss(). Step 2 and 3 are in tcp_process_loss(). The basic version is not supported because SACK enhanced version also works for non-SACK connections. The new implementation is functionally in parity with the old F-RTO implementation except the one case where it increases undo events: In addition to the RFC algorithm, a spurious timeout may be detected without sending data in step 2, as long as the SACK confirms not all the original data are dropped. When this happens, the sender will undo the cwnd and perhaps enter fast recovery instead. This additional check increases the F-RTO undo events by 5x compared to the prior implementation on Google Web servers, since the sender often does not have new data to send for HTTP. Note F-RTO may detect spurious timeout before Eifel with timestamps does so. Signed-off-by: Yuchung Cheng <ycheng@google.com> Acked-by: Eric Dumazet <edumazet@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation/networking')
-rw-r--r--Documentation/networking/ip-sysctl.txt18
1 files changed, 6 insertions, 12 deletions
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 8a977a0aaede..f98ca633b528 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -225,19 +225,13 @@ tcp_fin_timeout - INTEGER
225 Default: 60 seconds 225 Default: 60 seconds
226 226
227tcp_frto - INTEGER 227tcp_frto - INTEGER
228 Enables Forward RTO-Recovery (F-RTO) defined in RFC4138. 228 Enables Forward RTO-Recovery (F-RTO) defined in RFC5682.
229 F-RTO is an enhanced recovery algorithm for TCP retransmission 229 F-RTO is an enhanced recovery algorithm for TCP retransmission
230 timeouts. It is particularly beneficial in wireless environments 230 timeouts. It is particularly beneficial in networks where the
231 where packet loss is typically due to random radio interference 231 RTT fluctuates (e.g., wireless). F-RTO is sender-side only
232 rather than intermediate router congestion. F-RTO is sender-side 232 modification. It does not require any support from the peer.
233 only modification. Therefore it does not require any support from 233
234 the peer. 234 By default it's enabled with a non-zero value. 0 disables F-RTO.
235
236 If set to 1, basic version is enabled. 2 enables SACK enhanced
237 F-RTO if flow uses SACK. The basic version can be used also when
238 SACK is in use though scenario(s) with it exists where F-RTO
239 interacts badly with the packet counting of the SACK enabled TCP
240 flow.
241 235
242tcp_keepalive_time - INTEGER 236tcp_keepalive_time - INTEGER
243 How often TCP sends out keepalive messages when keepalive is enabled. 237 How often TCP sends out keepalive messages when keepalive is enabled.