 | 1 | initial version |
Interesting case that requires some RFC reading. I did not read all RFC's regarding the subject, but some reading result in the following:
RFC 5681 states in paragraph 2:
DUPLICATE ACKNOWLEDGMENT: An acknowledgment is considered a
"duplicate" in the following algorithms when (a) the receiver of
the ACK has outstanding data, (b) the incoming acknowledgment
carries no data, (c) the SYN and FIN bits are both off, (d) the
acknowledgment number is equal to the greatest acknowledgment
received on the given connection (TCP.UNA from [RFC793]) and (e)
the advertised window in the incoming acknowledgment equals the
advertised window in the last incoming acknowledgment.
This means that the receiver is not sending duplicate ACK's when it is increasing it's window size.
I would say this is a less then optimal implementation on the side of the receiver and should be fixed.
RFC 2988 states in paragraph 5:
Note that after retransmitting, once a new RTT measurement is
obtained (which can only happen when new data has been sent and
acknowledged), the computations outlined in section 2 are performed,
including the computation of RTO, which may result in "collapsing"
RTO back down after it has been subject to exponential backoff
(rule 5.5).
So I would expect the RTO timer to reset in between these retransmission so that the back-off mechanism only effects packets with the same sequence number. However since TCP segmentation offloading is in place, the behavior is now also dependant on the the implementation of the TSO feature. When I look at the packets, I think the TSO feature does not work very well with the OS TCP stack.
If you can do without TSO, I would suggest to try to test without TSO to see if the backoff mechanism is then only applied to packets with the same sequence number and not on all following packets.