3

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?

Improve this question

1 Answer 1

Reset to default
4

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.

EDIT: After reading your edited question I believe TCP timestamps are the answer you're looking for.

TCP timestamps are used in an algorithm known as Protection Against Wrapped Sequence numbers, or PAWS (see RFC 1323 for details). PAWS is used when the receive window crosses the sequence number wraparound boundary. In the case where a packet was potentially retransmitted it answers the question: "Is this sequence number in the first 4 GB or the second?" And the timestamp is used to break the tie.

Improve this answer
7
  • Sorry, but I am still confused about what you said. If the seqNum 0 and 1K will not be seen ever again. How can the sender send new packets to the receiver? Considering the fact that we are running out of sequence numbers
    – yantiz
    May 10, 2016 at 6:20
  • OK I see your edit and I will check that first.
    – yantiz
    May 10, 2016 at 6:21
  • 1
    Sorry, I submitted my post early so went back and added additional information. The title of this question refers to recognising out of order packets but your actual question seems to be about running out of sequence numbers. Can you please provide more information on what it is you're trying to understand? (By the way, I've added more information to my answer above.)
    – OzNetNerd
    May 10, 2016 at 6:23
  • Sorry for the confusion caused by my vague description of my question. I've noticed the graph you provided at the bottom of your answer, and there is a thing that I didn't know before. Does the receiver's window size have to be at most half of the maximum sequence number? I originally thought they could be the same...
    – yantiz
    May 10, 2016 at 6:30
  • I've edited my question and do my best to clarify it.
    – yantiz
    May 10, 2016 at 6:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.