Does Wireshark not count a Duplicate-ACK if it also contains a Receive Window change?

Question

In the capture included with Ask Wireshark question #60530, there were acknowledgement packets #17-#23 and #28-#31 that were Dup-ACKs but each also increased the Receive Window size.

Due to the receive window increase, Wireshark reported them as a "TCP Window Update" but did not report them as "Duplicate ACK".

It also seems that the receiving client also didn't treat them as Dup-ACKs.

1) Can anyone confirm that the Wireshark code explicitly decides not to treat a Dup-ACK as such if it also contains an increment (or change) to the Receive Window value.

2) Does anyone know if this is a general TCP/IP rule, as suggested in the article:

https://www.ietf.org/mail-archive/web/tcpm/current/msg01200.html

3) Can anyone comment about the way these are handled in any TCP/IP implementations they are aware of.

Accepted Answer

For my question (2), I just found RFC 5681 which does define Dup-ACKs.

Start 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 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 in Question #60530 is behaving badly.

This means that my own answers to my questions are:

(1) Yes, Wireshark is indeed treating behaving correctly in the way it handles such ACK packets.

(2) Yes, it is a rule as defined in RFC 5681 Section 2.

(3) Therefore, we wouldn't expect any TCP stacks to treat such ACKs as Dup-ACKs.

Answer 2

I think this is the comment of the code block in question, taken from packet-tcp.c:

/* DUPLICATE ACK
 * It is a duplicate ack if window/seq/ack is the same as the previous
 * segment and if the segment length is 0
 */

yes, I think it is, but stacks behavior may vary (as always) :-)
I can't remember to have seen any trace where an ACK with a receive window change was considered a duplicate ACK.