mirror of
https://git.savannah.nongnu.org/git/lwip.git
synced 2025-08-04 21:44:38 +08:00
b1d3dcb8d7
According to rfc5681: https://tools.ietf.org/html/rfc5681 Paragraph 3.2. Fast Retransmit/Fast Recovery The TCP sender SHOULD use the "fast retransmit" algorithm to detect and repair loss, based on incoming duplicate ACKs. The fast retransmit algorithm uses the arrival of 3 duplicate ACKs (as defined in section 2, without any intervening ACKs which move SND.UNA) as an indication that a segment has been lost. After receiving 3 duplicate ACKs, TCP performs a retransmission of what appears to be the missing segment, without waiting for the retransmission timer to expire. Now consider the following scenario: Server sends packets to client P0, P1, P2 .. PK. Client sends packets to server P`0 P`1 ... P`k. I.e. it is a pipelined conversation. Now lets assume that P1 is lost, Client will send an empty "duplicate" ack upon receive of P2, P3... In addition client will also send a new packet with "Client Data", P`0 P`1 .. e.t.c. according to sever receive window and client congestion window. Current implementation resets "duplicate" ack count upon receive of packets from client that holds new data. This in turn prevents server from fast recovery upon 3-duplicate acks receive. This is not required as in this case "sender unacknowledged window" is not moving. Signed-off-by: Solganik Alexander <sashas@lightbitslabs.com>