Tags:


Forum Replies

  1. Hi Zaman,

    Originally the window size is a 16 bit value so the largest window size would be 65535. We couldn’t add more bits to the TCP header but it was possible to reassign the purpose of those 16 bits.

    What we do nowadays is that we use a scaling factor so that we can use higher window sizes.

    For example, the window size value is 400 and the scaling factor is 64.

    400 x 64 = 25600

    In my lesson one of the screenshots also showed a windows size of 132480.

    Window size value = 2070
    Window size scaling factor = 64

    2070 x 64 = 132480

    Here’s a short explanation of the relative sequence and ACK numbers:

    TCP Header explained

    Rene

  2. 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!

    Laz

  3. 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.

  4. 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!

    Laz

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

    Azm

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