Rx: Reject out of order ACK packets
authorSimon Wilkinson <sxw@your-file-system.com>
Mon, 11 Oct 2010 17:14:02 +0000 (13:14 -0400)
committerDerrick Brashear <shadow@dementia.org>
Mon, 18 Oct 2010 17:18:12 +0000 (10:18 -0700)
commit4e71409fe1305cde4b9b341247ba658d8d24f4d0
treeca5be197c8555336142f9613d583194eb5a6f8a5
parent98688ddf70cbfe21d22e5832b2f50d626b4183e9
Rx: Reject out of order ACK packets

Our RX implementation virtually guarantees that we will see out of
order ACK packets, even on well behaved networks, as we send acks
simultaneously from multiple threads.

Currently we only reject out-of-order ACKS which change the window
position (so a window that advances, can never go back). However,
we fail to deal with the explicit acknowledgement portion of the ACK
packet in the same way...

For example, if we have a packet A that acknowledges packets 1 and 2,
and then a packet B acknowledging 1,2,3 and 4. If B arrives before A,
then we mark 1, 2, 3, 4 as acknowledged, and then treat the arrival of
A as nAcking 3 and 4. This has the same effect as an explicitly stated
nack, triggers an early and unnecessary resend and may, in some situations,
cause the call to go into congestion avoidance.

We can solve this using the previousPacket field of the ACK. This
indicates the last packet seen by the peer. In the same way as
firstPacket, this should never go backwards, and so can be used to
detect out of order acknowledgements, and reject them.

Change-Id: I9ad850872a1a62050e774c911302a65bb8a59525
Reviewed-on: http://gerrit.openafs.org/2958
Tested-by: Derrick Brashear <shadow@dementia.org>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
src/rx/rx.c
src/rx/rx.h