Question regarding TCP traffic capture and TCP RENO

There is a real packet loss at the beginning of the capture.

Data packets #6 & #7 are OK (ACKed by #15 & #16), then there's a gap that should trigger Dup-ACKs in response to each of #8-#14. So we should get 7 Dup-ACKs.

From a pure "ACK Sequence Number" perspective, #17-#23 are those Dup-ACKs, which all acknowledge the data up to data packet #7 (before the missing packet).

Data packets #24-#27 should also trigger Dup-ACKs. Again, #28-#31 are those Dup-ACKs too, again acknowledging just up to #7.

However, #17-#23 and #28-#31 each also increase the Receive Window size.

I think that core of the problem (at least for your first question) is the definition of "Duplicate ACK". I think that Wireshark, your receiving client and the commercial packet analysis software that I use, do not count these as Duplicate-ACKs because they also include the window size increase.

I found RFC 5681 that defines Dup-ACKs. (Earlier RFCs 2001 and 2581 discuss them but don't mention what should happen if a Dup-ACK also contains a changed window value).

Start of quote.

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.

Alternatively, a TCP that utilizes selective acknowledgments (SACKs) [RFC2018, RFC2883] can leverage the SACK information to determine when an incoming ACK is a "duplicate" (e.g., if the ACK contains previously unknown SACK information).

End of quote.

It would therefore appear that a receiver should not include Receive Window changes in any ACK packets that it wants to be treated as Dup-ACKs.

Thus, the TCP stack in the receiving client is behaving badly.

Under this definition, the Dup-ACKs seen in your capture are not classified as Dup-ACKs, even though they are each indicating an acknowledgement of the same data.

Now, since the sending server doesn't interpret these as Dup-ACKs, it appears to wait for a Retransmission Timeout (RTO) of 2.8 seconds before filling in the gap with #32.

Later in the capture, we see #64 but it is lost before it gets to the client. There are many Dup-ACKs in response to that gap (as seen at the receiving client) before it is filled in by #132 (a retransmission of #64).

There is another real gap between #113 & #114 which is filled in by #148. This is a faster gap fill, partially due to the Dup-ACKs from #64.

Lastly, #150 is a retransmission of #130 (which we saw but must have been lost before it got to the client).

Other observations:

Yes, based on those 3-way handshake times, we would deduce that the capture point is 480 ms away from the client and a further 200 ms away from the server. Is this artificial or are your end-points on the opposite sides of the world?

It looks like this client is generating ACKs to every data packet rather than doing the usual delayed ACK mechanism (which only ACKs every second data packet). Did you purposely configure this or is the default behaviour of your client TCP stack?

Can you tell us what your client is - so that we can be aware to look out for this behaviour in future?