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".
0because that is not the next data expected.