[SCTP]: Fix persistent slowdown in sctp when a gap ack consumes rx buffer.
authorNeil Horman <nhorman@tuxdriver.com>
Sun, 18 Jun 2006 05:59:03 +0000 (22:59 -0700)
committerDavid S. Miller <davem@davemloft.net>
Sun, 18 Jun 2006 05:59:03 +0000 (22:59 -0700)
commitd5b9f4c083b0e3102f3101545279f623680cb3a0
tree86d5f77d14a8ae687e585ec4535ca8038e450ab9
parentd7c2c9e3977e4312d093ac092761798d4d47c9e0
[SCTP]: Fix persistent slowdown in sctp when a gap ack consumes rx buffer.

In the event that our entire receive buffer is full with a series of
chunks that represent a single gap-ack, and then we accept a chunk
(or chunks) that fill in the gap between the ctsn and the first gap,
we renege chunks from the end of the buffer, which effectively does
nothing but move our gap to the end of our received tsn stream. This
does little but move our missing tsns down stream a little, and, if the
sender is sending sufficiently large retransmit frames, the result is a
perpetual slowdown which can never be recovered from, since the only
chunk that can be accepted to allow progress in the tsn stream necessitates
that a new gap be created to make room for it. This leads to a constant
need for retransmits, and subsequent receiver stalls. The fix I've come up
with is to deliver the frame without reneging if we have a full receive
buffer and the receiving sockets sk_receive_queue is empty(indicating that
the receive buffer is being blocked by a missing tsn).

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/sctp/sm_statefuns.c