Forum Replies

  1. Hello Hussein!

    First lets take a look and see what is meant by the window size: The window size indicates the size of a device's receive buffer for the particular connection. In other words, window size represents how much data a device can handle from its peer at one time before it is passed to the application layer. This buffer size can change based on the hardware being used (physical memory available on the NIC for buffering for example) as well as by the total number of TCP sessions the device is taking part in at any given time. Of course this window size may change dynamically. If there are too many errors, the window may become smaller. If there are no errors and other TCP sessions have ended and buffer space on the NIC is available, the window may get bigger. The actual value of the window size that is sent by a device to its peer is calculated by the OS of the device based on the above characteristics.

    It is important to note here that window size is also affected by latency as well as bandwidth. Under "normal" or more common circumstances, these factors don't enter into the equation. There are however cases where you would want to tweak the window size, and such an occasion is described below.

    The maximum window size is configured based on the usual latency and bandwidth that we see in the vast majority of networks. However, on high speed high latency networks such as the connections between countries and continents, regular TCP window sizes won't cut it. On these networks, small receive window sizes can limit throughput to a fraction of the available bandwidth.

    If the window size is too small, a sender may transmit an entire TCP window’s worth of data very fast (high bandwidth), and then have to wait until the packets reach the distant remote site (high latency) so that acknowledgements can be returned, informing the sender of successful data delivery and available receive buffer space. In such a situation, there is a lot of time wasted without sending data. In these cases, window size must be increased beyond what would normally be the case in a LAN or WAN.

    So it is possible to increase the window size, however, these changes would be done on the end devices that have created the TCP session and how that would be done depends in the systems used. TCP is layer 4 so routing and switching devices in between will not have any information concerning the TCP session details.

    I hope this has been helpful!


  2. Really excellent explanation on a very difficult topic. The wireshark captures really illustrate the points. This is the best way I have seen this topic described to get the idea across.

  3. Hello Azm

    Yes, these numbers can be confusing. Here is an attempt to clarify these parameters:

    The first thing to keep in mind is that in any TCP communication, there are actually TWO sequence numbers and TWO acknowledgement numbers: those of each party in the exchange of data. For the sake of this example, and for the diagram below, let's call these SNL and SNR for Sequence Number Left and Sequence Number Right for the left and right hosts. Similarly, the acknowledgement numbers will be called ANL and ANR.

    Note, these abbreviations are my own and are not generally accepted. I am using them only for the purpose of this example.

    Take a look at this diagram:

    The current state of this diagram is when the three way handshake has already been completed and transmission of data has begun. The current window size is 10.

    So, the left host begins transmitting and sends a frame where SNL is 1 and ANL is 1. The SNL and ANL have been determined after the procedure of the three way handshake. (To find out how these are initially determined, take a look at Rene's lesson here: https://networklessons.com/cisco/ccna-routing-switching/introduction-to-tcp-and-udp/ )

    Since the window size is 10, the left host will send 10 bytes (this can be sent in one or more segments) and the header of the segment will have an SNL of 1 and an ANL of 1. Once 10 bytes are sent (the window size) the left host will stop.

    The right host will continue to receive data and will do nothing until 10 bytes have been received. Once they have been received, it will compose an acknowledgement segment with the following information:

    SNR = 1 This has been determined after the three way handshake. Note this is independent of the SNL
    ANR = SNL + window size = 11 This essentially is the number of the next expected byte

    Once this acknowledgement segment is received by the left host, it prepares the next batch of bytes to be sent, specifically, 10 since the window size is 10. In the segment it sends, it puts the following values:

    SNL = ANR = 11
    ANL = SNR + 1 = 2

    And the process continues.

    I hope this has been helpful!


  4. Hello AZM

    I can understand the confusion. Keep in mind that the window size, the sequence number and the number of segments sent are somewhat independent from each other. What do I mean?

    Well, let's say we have a window size of 21000 bytes. It is very unlikely that this will all be sent in one segment. It will definitely be split into several segments. The window size is "the number of bytes sent before an acknowledgement is required from the receiver." These bytes can be sent in one or more segments. So, let's take the following example:

    Host A is sending a total of 100000 bytes (or 1 KB) of data to Host B. The window size is 7000 bytes. Let's say the maximum segment size (which is affected by the Layer 2 and Layer 3 MTU configuration) is 1500 bytes. Host A will begin sending a series of segments with the following elements (SEQa is the sequence number sent by host A):

    Segment 1: SEQa = 1, Window Size = 7000, segment size = 1500 Bytes
    Segment 2: SEQa = 1501, Window Size = 7000, , size = 1500 Bytes
    Segment 3: SEQa = 3001, Window Size = 7000, , size = 1500 Bytes
    Segment 4: SEQa = 4501, Window Size = 7000, , size = 1500 Bytes
    Segment 5: SEQa = 6001, Window Size = 7000, , size = 1000 Bytes

    At this point, 7000 bytes have been sent. The TCP window has been exhausted. Host A stops sending and waits for a response. Assuming all went well, Host B send the following response:

    Acknowledgement from Host B to Host A: ACKb = 7001

    The ACKb number returned is the next expected byte, that is, byte 7001.

    Once Host A successfully receives this acknowledgement, it continues with the next batch of segments:

    Segment 1: SEQa = 7001, Window Size = 7000, , segment size = 1500 Bytes
    Segment 2: SEQa = 8501, Window Size = 7000, , size = 1500 Bytes
    Segment 3: SEQa = 10001, Window Size = 7000, , size = 1500 Bytes
    Segment 4: SEQa = 11501, Window Size = 7000, , size = 1500 Bytes
    Segment 5: SEQa = 13001, Window Size = 7000, , size = 1000 Bytes

    Host B sends the following response

    Acknowledgement from Host B to Host A: ACKb = 14001

    ... and so on...

    So to specifically answer your question, yes sequence number is used to put the segments back in the proper order while window size is the number of bytes that must be sent before an acknowledgement must be received.

    It just happens that in both my example and Rene's example, the window size was very small, so only one segment was necessary to exhaust the window. That is why it seemed that the sequence number was directly related to the window size.

    As for your second question:

    One more thing is very confusing to me. In Rene's tutorial, he is saying "H1 has setup a connection with H2 by using the 3 way handshake. We are sending 10 bytes of Data which means our “window size” is 10 bytes. The sequence number is 10", but in your example even though when Left device is sending the first chunk of data of 10 bytes, still the sequence number is 1. I am not sure why. Would you please explain it to me?

    When beginning a transfer, the SEQ number in the header refers to the first byte that is being sent in that specific segment. But you must also keep in mind that the first SEQ number is always generated randomly, so it can be anything between 0 and something over 4 billion (32 bits represent the SEQ number). It is possible that @ReneMolenaar is using a random number in that example and it just happened to be 10. This can be confusing, and I can ask Rene to look it over and see if it needs revising.

    As for the field in the header that indicates the amount of data, there is no such field per se. However, this can be determined by examining the subsequent SEQ numbers in each received segment. Also, when the segments are received on the other end, at the end of the current window, the ACK number that is returned indicates the next expected byte, which in essence reveals the size of the last segment.

    I hope this has been helpful!


  5. Hello Laz,
    Once again SPECTACULAR. Thanks for your great help.


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