1- Just as the message ID that is assigned to each message in PAR, the "sequence number" is a means of providing reliability in a transfer of a byte stream. So sequence numbers are assigned to every single byte.

2- But not all the bytes are acknowledged because that would be too slow. So (according to Kozierok's book) seq# and ack# are planned to be only the number of the first byte of a sent segment and the number of the last byte of a received segment respectively. (ignoring all the nuances here like accumulative/selective acknowledgment and etc, since they are irrelevant to the questions here).

3- Through the exchange of the first three packets, the ISN of each side is announced to the other side and acknowledged(Thank you Eddie). But, in the third packet exchange, when the client is acknowledging the reception of the server's ISN, the seq# and ack# are both 1.

4- Here are my two questions:

Question 1: ISN (like seq#) is a 32-bit number, i.e 4 bytes. So Why isn't the ack# returned by the server, 3 (counting from 0) instead of 1 in the second packet exchanged? And similarly why aren't both the seq# and ack#, 3 instead of 1 in the third packet exchanged? Is this an exception* forced by those who designed the protocol or there are other reasons?

Now, in case the answer is that these initial incrementings are exceptionally counted as only 1 byte, then it brings us to a second question:

Question 2: Why do we engage the ISN exchange in seq# & ack# incrementing at all? One might say we have no other ways of announcing acknowledgements other than changing the ack#, but IMO that's not true. Both the server and the client could just check the SYN and the ACK flags to realize everything.

So where am I wrong? Please let me know if there's anything I've understood wrong. Thank you in advance.

* It is not explicitly stated anywhere I've checked that this is an "exception", but I've found this article which says: "SYN, FIN or ZeroWindow segments count as 1 byte for SEQs/ACKs.". So my personal interpretation from this line is that we're talking about an "exception".

  • 1
    An acknowledgement number is sent to tell the other side what the sender of the acknowledgement number expects next. It is acknowledging everything prior to the acknowledgement number, but the number is the next expected data. That means an acknowledgment number would not be 0 because that is not the next data expected. – Ron Maupin Jan 23 at 19:57
  • 1
    Also, you seem to think TCP has servers and clients, but it does not. TCP creates connections between peers, where each side is equal, can send data, receive data, and end the connection. Neither side is in control. The client/server concept is an application-layer concept, where the server provides a service (hence the name "server") to a client that consumes the service. That is an application concept. TCP is just like a wire between applications, and neither end of the wire is in charge. – Ron Maupin Jan 23 at 20:01

So (according to Kozierok's book) seq# and ack# are planned to be only the number of the first byte of a sent segment and the number of the last byte of a received segment respectively.

Either you misinterpreted what the book says, or the book is wrong. The acknowledgement number is not the last number of the sent segment, it is the sequence number of the next expected segment. The acknowledgement number, when combined with the ACK flag, tells the other side that is acknowledges all data prior to the acknowledgment number, but the number itself represents the next expected sequence number.

You should read RFC 793, Transmission Control Protocol, which is the definition of TCP. That is clearly explained in the RFC:

2.6. Reliable Communication

A stream of data sent on a TCP connection is delivered reliably and in order at the destination.

Transmission is made reliable via the use of sequence numbers and acknowledgments. Conceptually, each octet of data is assigned a sequence number. The sequence number of the first octet of data in a segment is transmitted with that segment and is called the segment sequence number. Segments also carry an acknowledgment number which is the sequence number of the next expected data octet of transmissions in the reverse direction. When the TCP transmits a segment containing data, it puts a copy on a retransmission queue and starts a timer; when the acknowledgment for that data is received, the segment is deleted from the queue. If the acknowledgment is not received before the timer runs out, the segment is retransmitted.

An acknowledgment by TCP does not guarantee that the data has been delivered to the end user, but only that the receiving TCP has taken the responsibility to do so.

To govern the flow of data between TCPs, a flow control mechanism is employed. The receiving TCP reports a "window" to the sending TCP. This window specifies the number of octets, starting with the acknowledgment number, that the receiving TCP is currently prepared to receive.

| improve this answer | |
  • 1- Page 854 of the book I mentioned has this line: "Instead of acknowledging using something like a message ID field, we acknowledge data using the sequence number of the last byte of data in the segment". 2- Even if that's the case(what you said is right), then should the numbers increment only by 1? (I've not read the RFC you linked to yet, if the answer is in there, let me know. Thanks Ron.) – aderchox Jan 23 at 20:39
  • 1
    I quoted the RFC. That sentence in that book is wrong. Simply read the portion of the RFC which I have highlighted in bold/italic. Think about what is happening in the handshake. Until any data are sent, the next expected data is 1, so the acknowledgement number is 1. Once data are received, the acknowledgment number will be the next expected sequence number. Segments carrying no data do not increment the sequence or acknowledgement numbers. – Ron Maupin Jan 23 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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