[lwip-users] [lwip] Fast Retransmit bug

[Kieran Mansley]

I see quite a few fast retransmits when there has been no packet loss or
reordering.  This is probably aggravated by the changes I've made to the
stack, but the underlying problem is as follows.

When data has been processed by the application it calls tcp_recved.  This
increases the advertised window, and sends an ack to transmit the window
update.  However, if the application processes a whole batch of packets at
once, it can end up calling tcp_recved many times in quick succession.
This can result in a few acks being transmitted before any more packets
arrived, and so they all ack the same sequence number.

When these are received by the other end, it is interpreting this as an
indication of packet loss, and doing a fast retransmit.  I think the
algorithm used here is in error.

RFC 1122 says:
  "One reason for ACKing out-of-order segments might be to
  support an experimental algorithm known as "fast
  retransmit".   With this algorithm, the sender uses the
  "redundant" ACK's to deduce that a segment has been
  lost before the retransmission timer has expired.  It
  counts the number of times an ACK has been received
  with the same value of SEG.ACK and with the same right
  window edge."

The missing bit in lwip is the check on the acks having the same right
window edge.  If it did so, it would see the acks are all just increasing
the advertised window, rather than being duplicates, and so not perform
the fast retransmit.

This should be simple to fix, but I would welcome any comments.

Kieran

[This message was sent through the lwip discussion list.]