{"id":1595,"date":"2010-05-30T15:21:54","date_gmt":"2010-05-30T09:51:54","guid":{"rendered":"http:\/\/www.jeffrin.in\/?p=1595"},"modified":"2010-05-30T15:21:54","modified_gmt":"2010-05-30T09:51:54","slug":"forward-rto-recovery-f-rto-defined-in-rfc4138","status":"publish","type":"post","link":"https:\/\/www.trueangle.org\/index.php\/2010\/05\/30\/forward-rto-recovery-f-rto-defined-in-rfc4138\/","title":{"rendered":"Forward RTO-Recovery (F-RTO) defined in RFC4138"},"content":{"rendered":"
\n$cat \/proc\/sys\/net\/ipv4\/tcp_frto\n2\n$\n<\/pre>\n
\nEnables Forward RTO-Recovery (F-RTO) defined in RFC4138.\n        F-RTO is an enhanced recovery algorithm for TCP retransmission\n        timeouts.  It is particularly beneficial in wireless environments\n        where packet loss is typically due to random radio interference\n        rather than intermediate router congestion.  F-RTO is sender-side\n        only modification. Therefore it does not require any support from\n        the peer.\n\n        If set to 1, basic version is enabled.  2 enables SACK enhanced\n        F-RTO if flow uses SACK.  The basic version can be used also when\nSACK is in use though scenario(s) with it exists where F-RTO\n        interacts badly with the packet counting of the SACK enabled TCP\n        flow.\nsource: linux kernel documentation.\n<\/pre>\n
\nExisting loss recovery techniques are not effective in dealing with\npacket losses and new techniques must be developed to handle\nthem. Almost 50% of all losses required a coarse timeout to\nrecover. Fast retransmissions recovered from less than 45% of all\nlosses. The remainder of losses were during slow start following\na timeout.\n\nFuture network implementations should increase their default\nsocket buffer size to avoid the receiver window from becoming a\nbottleneck. The socket buffer size limited the throughput of\napproximately 14% of all observed connections.\n\nA client using a collection of parallel connections between a client\nand server is a more aggressive user of the network than an\napplication that uses a single TCP connection. Throughput is\npositively correlated with the number of active connections.\nWhen multiple connections are concurrently active and one of\nthem experiences a loss, only half of the remaining ones on average\nexperience a loss. The combined congestion window of a\ngroup of parallel connections does not decrease as much as the\ncongestion window of a single connection after a loss epoch.\n\n\nOf a group of parallel connections, ones with small outstanding\nwindows could experience a larger number of losses than their\nshare of the total outstanding window would warrant. This\nmeans that it may be harder to initiate a new connection than to\nkeep an existing connection going.\n\nsource :\nTCP Behavior of a Busy Internet Server: Analysis and Improvements\nHari Balakrishnan*, Venkata N. Padmanabhan*, Srinivasan Seshan+, Mark Stemm*, Randy H. Katz*\n<\/pre>\n
\ncode fragments.\n\n \/* Abort F-RTO algorithm if one is in progress *\/\n        tp->frto_counter = 0;\n\n \/* Do not perform any recovery during F-RTO algorithm *\/\n        if (tp->frto_counter)\n                return 0;\n\n\n\/* F-RTO spurious RTO detection algorithm (RFC4138)\n *\n * F-RTO affects during two new ACKs following RTO (well, almost, see inline\n * comments). State (ACK number) is kept in frto_counter. When ACK advances\n * window (but not to or beyond highest sequence sent before RTO):\n *   On First ACK,  send two new segments out.\n *   On Second ACK, RTO was likely spurious. Do spurious response (response\n *                  algorithm is not part of the F-RTO detection algorithm\n *                  given in RFC4138 but can be selected separately).\n * Otherwise (basically on duplicate ACK), RTO was (likely) caused by a loss\n * and TCP falls back to conventional RTO recovery. F-RTO allows overriding\n * of Nagle, this is done using frto_counter states 2 and 3, when a new data\n * segment of any size sent during F-RTO, state 2 is upgraded to 3.\n *\n * Rationale: if the RTO was spurious, new ACKs should arrive from the\n * original window even after we transmit two new data segments.\n *\n * SACK version:\n *   on first step, wait until first cumulative ACK arrives, then move to\n *   the second step. In second step, the next ACK decides.\n *\n * F-RTO is implemented (mainly) in four functions:\n *   - tcp_use_frto() is used to determine if TCP is can use F-RTO\n *   - tcp_enter_frto() prepares TCP state on RTO if F-RTO is used, it is\n *     called when tcp_use_frto() showed green light\n *   - tcp_process_frto() handles incoming ACKs during F-RTO algorithm\n *   - tcp_enter_frto_loss() is called if there is not enough evidence\n *     to prove that the RTO is indeed spurious. It transfers the control\n *     from F-RTO to the conventional RTO recovery\n *\/\n\nsource:  linux kernel sources. tcp_input.c\n\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
$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 … <\/p>\n
Continue reading “Forward RTO-Recovery (F-RTO) defined in RFC4138”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[1399],"_links":{"self":[{"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/posts\/1595"}],"collection":[{"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/comments?post=1595"}],"version-history":[{"count":0,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/posts\/1595\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/media?parent=1595"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/categories?post=1595"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.trueangle.org\/index.php\/wp-json\/wp\/v2\/tags?post=1595"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}