Sequence numbers of segments in three way handshakes of TCP connection establishment or termination

Question

I was trying to understand TCP connection establishment and termination steps from Forouzan's book.

In third step of three way handshake of connection establishment, it says following

The client sends the third segment. This is just an ACK segment. It acknowledges the receipt of the second segment with the ACK flag and acknowledgment number field. Note that the ACK segment does not consume any sequence numbers if it does not carry data, but some implementations allow this third segment in the connection phase to carry the first chunk of data from the client. In this case, the segment consumes as many sequence numbers as the number of data bytes.

Q1. I dont get bold faced sentence. It says third segment does not consume sequence number if it is only ACK and does not carry any data. But, in the diagram, both first and second segment is shown to have different sequence numbers 8000 and 8001. I felt both should be 8000.

In third step of three way handshake of connection termination, it says:

The client TCP sends the last segment, an ACK segment, to confirm the receipt of the FIN segment from the TCP server. This segment contains the acknowledgment number, which is one plus the sequence number received in the FIN segment from the server. This segment cannot carry data and consumes no sequence numbers.

Q2. Again I dont get bold faced sentence. It says if ACK segment does not carry data, it wont consume sequence number. But in diagram sequence numbers of first and third segments are different: x and x+1. I felt both should be x.

Am I making some mistake here to understand diagrams?

At some point later in the book, while explaining how re transmission timer is calculated, it shows connection establishment phase as follows:

Note that first and third segment have same sequence number, 1400. Then why first and second diagram have different sequence number in first and third segment? Should they have same sequence number or I am miss interpreting "consumes no sequence number"?

Answer 1

I think the part you are missing is that the acknowledgement number is the number of the data expected next. A segment with an ACK says I acknowledge everything before this acknowledgement number, and the next data I expect will start with this acknowledgement number as its sequence number.

In the first diagram, there is no acknowledgement number in the first segment (SYN) because the sender does not yet know what sequence number the receiver will use to start. The next segment (SYN and ACK) has both a sequence number, and the acknowledgement number is the sequence number it received plus one because that is what it expects next (any data next received would start with that sequence number). The ACK flag is set, so it is acknowledging receipt of everything prior to the acknowledgement number, and setting the expectation of what the next sequence number of data it receives should be. The third segment (ACK) also has the ACK flag is set, so it is also acknowledging receipt of everything prior to the acknowledgement number, and setting the expectation of what the next sequence number of data it receives should be.

If you understand that, then the second diagram also makes sense. Remember that almost every segment after the initial handshake will carry both data and have the ACK flag set. The FIN segment could be carrying data, too; it is simply telling the other side that it is done sending, but the other side could continue to send data until it is done. Apparently, the other side is also done, replying with a FIN, but also an ACK and the acknowledgement number needs to be X + 1 to indicate that it acknowledges everything less than that, and any data received next would need to start at X + 1.

In the third diagram, the two segments that have the sequence number of 1400 are correct because neither shows to be carrying any data. It is the data that determines the sequence number, and it is what is next expected in the acknowledgement number.

Answer 2

Q1: Even if it is not carrying data, the SYN segment is consumming one byte in the sequence numbers, because the SYN flag must be acked by peer. That's why the server replies with an ACK of 8001 and the next client segment sequence number is 8001.

Q2: The FIN Flag must also be acked (so +1 in server reply) and means "I'm done with sending data". That's why after that segment, the client cannot send any data anymore (but it can still receive from server as long this one has not sent FIN flag yet).

In the third diagram, it is a glitch since SYN flag counts as 1 byte (the peer acknowledges correctly the SYN. In real network, this would trouble the server since it looks like a retransmission without the SYN flag...). The sequence number of the third segment should be 1401 (like the fourth segment).

Answer 3

The last image has some serious flaws. If this is about retransmission of ACKs it also shows Pipelining., TDACKs, Fast Retransmit and cumulative ACKs

Host A                          Host B
 ---SQN: 1400 ACK-Flag 0 -->      }
 <--SQN: 4001 ACK: 1401  ---      | 3-Way-Handshake
 ---SQN: 1401 ACK: 4001  -->      } Host A could start sending Data
                                     here already
    SQN: 4001 ACK: 1402  <--      | ACK of Host B gets lost on its 
                                          
  ---SQN: 1402 ACK: 4001  -->     } 
    data :1402-1500 Bytes         | A is pipelining its data  
  ---SQN: 1501 ACK: 4001  -->     | and repeats the next expected
    data :1501-1600 Bytes         | Byte from Host B
  ---SQN: 1601 ACK: 4001  -->     | 
    data :1601-1700 Bytes         }

  <--SQN: 4001 ACK: 1701  ---    | B received triple duplicate 
                                 | (TDACK) and knows now, that
                                 | SQN 4001 got lost, resends
                                 | it along a cumulative ACK