# How does a TCP sender recognize out-of-order ACK packets?

I am a new learner of TCP protocol and recently a question puzzles me for a period...

My question arises from the following example:

Suppose our MSS is 1KB and the maximum sequece number is 30K-1. We can ignore the congestion control window and assume the receiver's window size is constantly 30K (receiver is able to instantly deliver the data in segment to the application layer).

Suppose the initial seqNum is 0, and sender simultaneously sends out 30 packets with seqNum 0, 1K, 2K ... 28K and 29K respectively.

The receiver successfully accepts all 30 packets and replies with 30 ACK packets accordingly, each with ack number 1K, 2K, ... 29K and 0. (This is where the first ACK packet 1K appears)

However, due to the out of order delivery, the sender gets ack number 2K before 1K. Although for now it is still not a problem, because sender can deduce that the first two packets are accepted through the principle of accumulative acknowledgement.

Then, sender sends two more packets with seqNum 0 and 1K with newer data (sequencer number 0 and 1K are reused due to sequence number looping back), and receiver accepts them and reply with ACK packets 1K, 2K. (This is where the second ACK packet 1K appears)

However, this caused a problem that there exists two ACK packets with ack number all being 1K. How can the sender tell which ACK packet is newer than the other?

Then, sender sends two more packets with seqNum 0 and 1K, and receiver accepts them and reply with ACK packets 1K, 2K.

The sequence and ACK numbers are cumulative, therefore once a packet is ACKed that sequence number will not be seen in that TCP stream ever again (well they will be eventually if the session sends enough data - see this thread for more information). See the "Statistics > Flow Graph" image in this PacketLife post for information on the how the ACK and SEQ figures increment.

In regards to ACK'ing out of order packets, this is done through SACK as described in this PacketLife post.