1. 29 Nov, 2011 35 commits
  2. 28 Nov, 2011 3 commits
  3. 27 Nov, 2011 2 commits
    • Neal Cardwell's avatar
      tcp: skip cwnd moderation in TCP_CA_Open in tcp_try_to_open · 8cd6d616
      Neal Cardwell authored
      The problem: Senders were overriding cwnd values picked during an undo
      by calling tcp_moderate_cwnd() in tcp_try_to_open().
      
      The fix: Don't moderate cwnd in tcp_try_to_open() if we're in
      TCP_CA_Open, since doing so is generally unnecessary and specifically
      would override a DSACK-based undo of a cwnd reduction made in fast
      recovery.
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8cd6d616
    • Neal Cardwell's avatar
      tcp: allow undo from reordered DSACKs · f698204b
      Neal Cardwell authored
      Previously, SACK-enabled connections hung around in TCP_CA_Disorder
      state while snd_una==high_seq, just waiting to accumulate DSACKs and
      hopefully undo a cwnd reduction. This could and did lead to the
      following unfortunate scenario: if some incoming ACKs advance snd_una
      beyond high_seq then we were setting undo_marker to 0 and moving to
      TCP_CA_Open, so if (due to reordering in the ACK return path) we
      shortly thereafter received a DSACK then we were no longer able to
      undo the cwnd reduction.
      
      The change: Simplify the congestion avoidance state machine by
      removing the behavior where SACK-enabled connections hung around in
      the TCP_CA_Disorder state just waiting for DSACKs. Instead, when
      snd_una advances to high_seq or beyond we typically move to
      TCP_CA_Open immediately and allow an undo in either TCP_CA_Open or
      TCP_CA_Disorder if we later receive enough DSACKs.
      
      Other patches in this series will provide other changes that are
      necessary to fully fix this problem.
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f698204b