Revert "dctcp: update cwnd on congestion event"
authorFlorian Westphal <fw@strlen.de>
Mon, 5 Dec 2016 23:23:00 +0000 (00:23 +0100)
committerDavid S. Miller <davem@davemloft.net>
Tue, 6 Dec 2016 16:34:24 +0000 (11:34 -0500)
commit343dfaa198e98e8195a962c53206ad88076a6066
tree1fc98d50d762a266349f8ed197a903bd617171ab
parentb1df0f5ceab3cf0207dcb585c51424fe1bb1e1d2
Revert "dctcp: update cwnd on congestion event"

Neal Cardwell says:
 If I am reading the code correctly, then I would have two concerns:
 1) Has that been tested? That seems like an extremely dramatic
    decrease in cwnd. For example, if the cwnd is 80, and there are 40
    ACKs, and half the ACKs are ECE marked, then my back-of-the-envelope
    calculations seem to suggest that after just 11 ACKs the cwnd would be
    down to a minimal value of 2 [..]
 2) That seems to contradict another passage in the draft [..] where it
    sazs:
       Just as specified in [RFC3168], DCTCP does not react to congestion
       indications more than once for every window of data.

Neal is right.  Fortunately we don't have to complicate this by testing
vs. current rtt estimate, we can just revert the patch.

Normal stack already handles this for us: receiving ACKs with ECE
set causes a call to tcp_enter_cwr(), from there on the ssthresh gets
adjusted and prr will take care of cwnd adjustment.

Fixes: 4780566784b396 ("dctcp: update cwnd on congestion event")
Cc: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/ipv4/tcp_dctcp.c