tcp_cubic: do not set epoch_start in the future
authorEric Dumazet <edumazet@google.com>
Thu, 17 Sep 2015 15:38:00 +0000 (08:38 -0700)
committerSasha Levin <sasha.levin@oracle.com>
Mon, 25 Apr 2016 15:57:09 +0000 (11:57 -0400)
commitaf05df01c7a9f4b3cf3dc29365f4c7c4e2cd53ff
treefe43e29e5fe1ce8e915c17fecde5fd2f364718c1
parent1d155a6c311d0e7855181638b3b8b6e76302fe6d
tcp_cubic: do not set epoch_start in the future

[ Upstream commit c2e7204d180f8efc80f27959ca9cf16fa17f67db ]

Tracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start
is normally set at ACK processing time, not at send time.

Doing a proper fix would need to add an additional state variable,
and does not seem worth the trouble, given CUBIC bug has been there
forever before Jana noticed it.

Let's simply not set epoch_start in the future, otherwise
bictcp_update() could overflow and CUBIC would again
grow cwnd too fast.

This was detected thanks to a packetdrill test Neal wrote that was flaky
before applying this fix.

Fixes: 30927520dbae ("tcp_cubic: better follow cubic curve after idle period")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Cc: Jana Iyengar <jri@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
net/ipv4/tcp_cubic.c