[tcp] Treat ACKs as sent only when successfully transmitted
authorMichael Brown <mcb30@ipxe.org>
Thu, 15 Jul 2010 18:33:46 +0000 (19:33 +0100)
committerMarty Connor <mdc@etherboot.org>
Sun, 1 Aug 2010 20:12:11 +0000 (16:12 -0400)
commit7c274bab1b4e753419646b3dcd5867a4baede85d
tree1a5e79f47b78f17e3f242c576cc26eb09d31648e
parent7cf46f8d65da8c7c408e73c31ec706bb1226f8a9
[tcp] Treat ACKs as sent only when successfully transmitted

gPXE currently forces sending (i.e. sends a pure ACK even in the
absence of fresh data to send) only in response to packets that
consume sequence space or that lie outside of the receive window.
This ignores the possibility that a previous ACK was not actually sent
(due to, for example, the retransmission timer running).

This does not cause incorrect behaviour, but does cause unnecessary
retransmissions from our peer.  For example:

 1. Peer sends final data packet (ack      106 seq 521..523)
 2. We send FIN                  (seq 106..107 ack      523)
 3. Peer sends FIN               (ack      106 seq 523..524)
 4. We send nothing since retransmission timer is running for our FIN
 5. Peer ACKs our FIN            (ack      107 seq 524..524)
 6. We send nothing since this packet consumes no sequence space
 7. Peer retransmits FIN         (ack      107 seq 523..524)
 8. We ACK peer's FIN            (seq 107..107 ack      524)

What should happen at step (6) is that we should ACK the peer's FIN,
since we can deduce that we have never sent this ACK.

Fix by maintaining an "ACK pending" flag that is set whenever we are
made aware that our peer needs an ACK (whether by consuming sequence
space or by sending a packet that appears out of order), and is
cleared only when the ACK packet has been transmitted.

Reported-by: Piotr JaroszyƄski <p.jaroszynski@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Marty Connor <mdc@etherboot.org>
src/net/tcp.c