tcp_cubic: better follow cubic curve after idle period
commit1d155a6c311d0e7855181638b3b8b6e76302fe6d
authorEric Dumazet <edumazet@google.com>
Thu, 10 Sep 2015 04:55:07 +0000 (9 21:55 -0700)
committerSasha Levin <sasha.levin@oracle.com>
Wed, 20 Apr 2016 05:13:13 +0000 (20 01:13 -0400)
tree3e0a030961db7b73befff1de84e086b1eecbfe4d
parentb016f99b40071aed628a24d08c61960fd77e553e
tcp_cubic: better follow cubic curve after idle period

[ Upstream commit 30927520dbae297182990bb21d08762bcc35ce1d ]

Jana Iyengar found an interesting issue on CUBIC :

The epoch is only updated/reset initially and when experiencing losses.
The delta "t" of now - epoch_start can be arbitrary large after app idle
as well as the bic_target. Consequentially the slope (inverse of
ca->cnt) would be really large, and eventually ca->cnt would be
lower-bounded in the end to 2 to have delayed-ACK slow-start behavior.

This particularly shows up when slow_start_after_idle is disabled
as a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle
time.

Jana initial fix was to reset epoch_start if app limited,
but Neal pointed out it would ask the CUBIC algorithm to recalculate the
curve so that we again start growing steeply upward from where cwnd is
now (as CUBIC does just after a loss). Ideally we'd want the cwnd growth
curve to be the same shape, just shifted later in time by the amount of
the idle period.

Reported-by: Jana Iyengar <jri@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: Sangtae Ha <sangtae.ha@gmail.com>
Cc: Lawrence Brakmo <lawrence@brakmo.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
net/ipv4/tcp_cubic.c