Why in TCP the first data packet is sent with "sequence number = initial sequence number + 1" instead of "sequence number = initial sequence number"?

Question

In the 3-way handshake, the initial sequence number of both endpoints of the TCP connection is synchronized.

Here is an example:

Endpoint A randomly generates an initial sequence number: 123.
Endpoint B randomly generates an initial sequence number: 678.

The endpoints agree that A will send the first data segment starting from 124, and endpoint B will start from 679.

Perfect.

However, I don't understand why they don't agree on sending their first data segment with their initial sequence numbers. Why don't they do something like this:

As you can see, there is no increment in the sequence number when the SYN packets are sent (because the data octet they send is 0). Therefore, the endpoints could agree that A will send the first data segment starting from 123, and endpoint B will start from 678.

What is the reason why the TCP protocol uses the "increase by 1" logic in the presence of a SYN segment, even if the data octet is 0?

You've been told the answer several times already, with references. Third time you've posted this question. — user207421, Jul 15 '23 at 04:37
@user207421 From the brilliant Eddie answer, I understand why TCP has been designed in that way for FIN segments. Without the phantom byte logic, the protocol doesn't work.
However, I believe that without the phantom byte logic, the protocol would still work for SYN segments. The TCP has been designed in this way primarily for consistency reasons.

Do you agree with this perspective, or do you think there are other reasons why the SYN segments should have the phantom byte logic?

(Please provide your own answer without references.) — ilBarra, Jul 15 '23 at 06:35
@ilkkachu: their two most recent posts on Stack Overflow: Why in TCP the first data packet is sent with "sequence number = initial sequence number + 1" instead of "sequence number = initial sequence number"? and Why in the 3 Way handshake the SYN packet cause an incremented ACK? — Peter Cordes, Jul 16 '23 at 20:22
@ilkkachu: They have comments like "RFC 793 #3.3 Sequence Numbers states that both SYN and FIN have sequence numbers, and explains why." which user207421 clearly felt was sufficient to point them in the right direction. I haven't looked into the details of what was asked and commented to decide whether that was a reasonable thing to say or not, but it's obviously what they're referring to. — Peter Cordes, Jul 16 '23 at 21:10
@PeterCordes, yes, perhaps. But I wasn't planning on arguing about this with you, so I'll leave it here. G'night. — ilkkachu, Jul 16 '23 at 21:25

Eddie · Accepted Answer · 2023-07-13T19:40:39.107

This "bump the sequence# forward by 1 for SYN and FIN flags" is sometimes referred to as the "Phantom Byte" -- since no actual byte of data is sent, but the presence of the SYN or FIN flag still increased the sequence number by 1.

The why behind it I think is easier to see with the FIN than it is for the SYN. And to show it I'll use this screenshot:

(source: TCP - 12 simple ideas to explain the Transmission Control Protocol @ ~38:05)

In this illustration, Alice & Bob are closing a TCP connection using FIN flags. Here is a quick description of the first 4 packets:

Packet#1 is Alice sending her last 200 bytes of data, SEQ 1401
Packet#2 is Bob acknowledging reception by sending ACK 1601
Packet#3 is Alice closing her side of the connection with a FIN, SEQ 1601
Packet#4 is Bob acknowledging reception by sending ACK 1602

Look at packet#2 and #4 -- notice one was Bob sending ACK 1601, and the other was ACK 1602. Notice the packets are identical, except for the ACK#

If the phantom byte didn't exist, then the ACK in packet#4 would (still) be 1601... and Alice would not be able to differentiate between packet#2 and packet#4 -- Which means Alice would not be able to determine whether this simply a resend or duplicate copy of packet#2, or a new ACK altogether.

the Phantom byte allows Bob to explicitly acknowledge the FIN, independent from acknowledging reception of data.

The same effect occurs a bit later with Packet #7 and #9 -- the increase of the ACK# sent by Alice allows us to differentiate these two packets:

Packet#7 is Alice ACKnowledging receiving the last byte of Data
Packet#9 is Alice ACKnowledging receiving the FIN from Bob

Granted, that explains the Phantom Byte from the FIN perspective, but maybe not exactly with the SYN. My best guess is TCP chose to use the Phantom Byte strategy for the SYN as well to keep things consistent.

The general rule with TCP is anything that TCP intends to have acknowledged will increase the Sequence number: Data, FIN packets, and SYN packets.

Disclaimer: I created the video from which the screenshot above was taken.

What an answer! Thank you Eddie a learnt a lot and I will also follow your youtube channel. I am new in the world of networking. Why you don't investigate a little bit with your connections about this so we will discover if about "SYN" your guess is true? Thank you again — ilBarra, Jul 13 '23 at 19:53
@ilBarra: if you like the answer so much, don't forget to click the grey check-mark below the score turning it into a beautiful green! ;-) — Fabby, Jul 14 '23 at 21:43
I check-marked the answer for the consensus it received. I was thinking that there were other reasons for that design choice instead looks like they did it just for consistency one. — ilBarra, Jul 15 '23 at 03:34

Why in TCP the first data packet is sent with "sequence number = initial sequence number + 1" instead of "sequence number = initial sequence number"?

1 Answers1