• Koen De Schepper's avatar
    tcp: Ensure DCTCP reacts to losses · aecfde23
    Koen De Schepper authored
    RFC8257 §3.5 explicitly states that "A DCTCP sender MUST react to
    loss episodes in the same way as conventional TCP".
    
    Currently, Linux DCTCP performs no cwnd reduction when losses
    are encountered. Optionally, the dctcp_clamp_alpha_on_loss resets
    alpha to its maximal value if a RTO happens. This behavior
    is sub-optimal for at least two reasons: i) it ignores losses
    triggering fast retransmissions; and ii) it causes unnecessary large
    cwnd reduction in the future if the loss was isolated as it resets
    the historical term of DCTCP's alpha EWMA to its maximal value (i.e.,
    denoting a total congestion). The second reason has an especially
    noticeable effect when using DCTCP in high BDP environments, where
    alpha normally stays at low values.
    
    This patch replace the clamping of alpha by setting ssthresh to
    half of cwnd for both fast retransmissions and RTOs, at most once
    per RTT. Consequently, the dctcp_clamp_alpha_on_loss module parameter
    has been removed.
    
    The table below shows experimental results where we measured the
    drop probability of a PIE AQM (not applying ECN marks) at a
    bottleneck in the presence of a single TCP flow with either the
    alpha-clamping option enabled or the cwnd halving proposed by this
    patch. Results using reno or cubic are given for comparison.
    
                              |  Link   |   RTT    |    Drop
                     TCP CC   |  speed  | base+AQM | probability
            ==================|=========|==========|============
                        CUBIC |  40Mbps |  7+20ms  |    0.21%
                         RENO |         |          |    0.19%
            DCTCP-CLAMP-ALPHA |         |          |   25.80%
             DCTCP-HALVE-CWND |         |          |    0.22%
            ------------------|---------|----------|------------
                        CUBIC | 100Mbps |  7+20ms  |    0.03%
                         RENO |         |          |    0.02%
            DCTCP-CLAMP-ALPHA |         |          |   23.30%
             DCTCP-HALVE-CWND |         |          |    0.04%
            ------------------|---------|----------|------------
                        CUBIC | 800Mbps |   1+1ms  |    0.04%
                         RENO |         |          |    0.05%
            DCTCP-CLAMP-ALPHA |         |          |   18.70%
             DCTCP-HALVE-CWND |         |          |    0.06%
    
    We see that, without halving its cwnd for all source of losses,
    DCTCP drives the AQM to large drop probabilities in order to keep
    the queue length under control (i.e., it repeatedly faces RTOs).
    Instead, if DCTCP reacts to all source of losses, it can then be
    controlled by the AQM using similar drop levels than cubic or reno.
    Signed-off-by: default avatarKoen De Schepper <koen.de_schepper@nokia-bell-labs.com>
    Signed-off-by: default avatarOlivier Tilmans <olivier.tilmans@nokia-bell-labs.com>
    Cc: Bob Briscoe <research@bobbriscoe.net>
    Cc: Lawrence Brakmo <brakmo@fb.com>
    Cc: Florian Westphal <fw@strlen.de>
    Cc: Daniel Borkmann <borkmann@iogearbox.net>
    Cc: Yuchung Cheng <ycheng@google.com>
    Cc: Neal Cardwell <ncardwell@google.com>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Andrew Shewmaker <agshew@gmail.com>
    Cc: Glenn Judd <glenn.judd@morganstanley.com>
    Acked-by: default avatarFlorian Westphal <fw@strlen.de>
    Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
    Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    aecfde23
tcp_dctcp.c 7.65 KB