tcp: do not rearm RTO when future data are sacked
authorYuchung Cheng <ycheng@google.com>
Thu, 24 Oct 2013 15:59:27 +0000 (08:59 -0700)
committerDavid S. Miller <davem@davemloft.net>
Sun, 27 Oct 2013 20:50:06 +0000 (16:50 -0400)
commit2f715c1dde6e1760f3101358dc26f8c9489be0bf
treeb77474cc9f3e97000404dab09bde3429d62192ff
parent2909d874f34eae157aecab0af27c6dc4a1751f8f
tcp: do not rearm RTO when future data are sacked

Patch ed08495c3 "tcp: use RTT from SACK for RTO" always re-arms RTO upon
obtaining a RTT sample from newly sacked data.

But technically RTO should only be re-armed when the data sent before
the last (re)transmission of write queue head are (s)acked. Otherwise
the RTO may continue to extend during loss recovery on data sent
in the future.

Note that RTTs from ACK or timestamps do not have this problem, as the RTT
source must be from data sent before.

The new RTO re-arm policy is
1) Always re-arm RTO if SND.UNA is advanced
2) Re-arm RTO if sack RTT is available, provided the sacked data was
   sent before the last time write_queue_head was sent.

Signed-off-by: Larry Brakmo <brakmo@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/ipv4/tcp_input.c