Tags: ,

Forum Replies

  1. Amruta,
    This has to do with how the sequence number is incremented during the TCP session. Let’s say Client A is requesting 900 Bytes of data from Server 1. Once Server 1 starts to send the actual data to Client A, the length of the payload of what is being sent directly influences the next sequence number.

    So, let’s say the current Sequence number is 1, and the Server sends Client A, 300 Bytes. This means the sequence number will now be 301 (the original sequence number plus the amount of data in the payload that was just sent). Now, let’s say, after Client A acknowledges the first 300 bytes, Server 1 sends Client A 450 bytes. The new sequence number will now be 751 (301 + 450). Finally, Server 1 sends what is remaining (the last 150 bytes). This means the final sequence number would be 901 (751 + 150).

    So, in this respect, the Sequence Number can be used to show the total amount of payload data that was transferred during a TCP session.


  2. Hello Mohammad

    When a TCP session is in progress, the sequence numbers are used to keep track of the number of bytes that have been transmitted within the session. When 100 bytes are sent from host A to host B, host B will respond with an ACK that is incremented by 100. If this is the beginning of the transaction and we started with a sequence number of 0, then the ACK that host B will send will be 100 indicating that the amount of data that has been received so far is 100 bytes.

    During the three way handshake, the first SYN packet is sent with an initial sequence number of 0, and has no data payload. That means that the number of bytes sent is 0. Even though the payload is 0, host B responds with an ACK incremented by 1. Because the SEQ and ACK numbers are associated with the number of bytes sent and received, when this occurs, we are actually incrementing the sequence numbers when no bytes have been sent. So this is referred to as the phantom byte, where 1 byte of payload is counted when 0 have been sent.

    I hope this has been helpful!


  3. Hello Hussein.

    First of all the sequence number doesn’t indicate how much data is sent, but the difference between the original sequence number and the acknowledgement number sent back to the reciever indicates the amount of data that has been sent in one window.

    Your first two questions have to do with something called windowing which is a flow control mechanism of TCP. Specifically, when a TCP session begins, the sequence number is chosen randomly. For example, let’s say the initial sequence number is 100588. During the initial handshake, the window size is also determined. This value is in bytes. Let’s say the initial window size is 10000 bytes.

    With these values, the sender begins to send segments of data until it sends the window size number of bytes. Then it waits for an acknowledgement. When the reciever recieves the 10000 bytes, it sends the acknolwegement which includes the next expected byte. The next expected byte is calculated as the initial sequence number plus the window size plus 1. So the reciever would send 100588 + 10000 + 1 = 110589 as the next expected byte.

    When the sender recieves this information, he begins sending the next “window” of data, that is the next 10000 bytes beginning with byte number 110589. (Remember that this value is a relative value and not an absolute value. It is relative to the original random sequence number.)

    Once those 10000 bytes are sent, the reciever sends an acknowledgement with the next expected byte which is 110589 + 10000 + 1 = 120590. The sender recives this acknowledgement and begins sending the next section of data beginning at byte number 120590 and so on.

    When the value of the sequence number becomes 4294967295, which is the maximum value a 32 bit binary number can have, it then wraps around to 0 and continues counting. The devices know that an original sequence number of 4294967290 with a final sequence number of 5 will have a difference of 10.

    As for your third question, the answer is yes. More accurately however, the window size determines the efficiency with which a link is utilized. Take a look at the excellent video found in this lesson which demonstrates how the window size affects the throughput of data.

    I hope this has been helpful!


  4. Hello Hussein

    Yes I understand the confusion. Keep in mind that if you take the first sequence number that was used when the session was initiated and the last sequence number that was used before termination, if you calculate the difference between them, it will indeed be the total amount of data in bytes that have been sent over the whole session (taking into account the number of times the sequence number has to be reset to zero when it reaches the upper limit of the 32 bit field).

    I hope this has been helpful!


  5. Hello Hussein

    Unfortunately there isn’t. Because the window size is always going to be much much smaller than the largest available sequence number, it will never reset to zero within a single segment. Segments are always many many orders of magnitude smaller. Only the hosts between them keep track of when the counter resets to zero. Even when it does, they only detect it at that specific segment. Once the segment is received and acknowledged, there is no need to keep track of the resetting of the counter from the host’s point of view.

    If you want to keep track of the total amount of data that has been sent in a session, there are other mechanisms that can do that, that belong to higher layers. For example, in an FTP transaction, FTP keeps track of bytes transferred and other such statistics.

    I hope this has been helpful!


19 more replies! Ask a question or join the discussion by visiting our Community Forum