TCP Window Scaling

Open NetSim, Select Examples->Internetworks->TCP Window Scaling then click on the tile in the middle panel to load the example as shown in below Figure.

Figure4-29

The following network diagram illustrates what the NetSim UI displays when you open the example configuration file for TCP Window scaling as shown in below Figure.

Figure4-30

The TCP throughput of a link is limited by two windows: the congestion window and the receive window. The congestion window tries not to exceed the capacity of the network (congestion control); the receive window tries not to exceed the capacity of the receiver to process data (flow control).

The TCP window scale option is an option to increase the receive window size allowed in Transmission Control Protocol above its former maximum value of 65,535 bytes.

TCP window scale option is needed for efficient transfer of data when the bandwidth-delay product is greater than 64K. For instance, if a transmission line of 1.5 Mbit/second was used over a satellite link with a 513 milliseconds round trip time (RTT), the bandwidth-delay product is 1500000 $\times$ 0.513 = 769,500 bits or about 96,187 bytes.

Using a maximum window size of 64 KB only allows the buffer to be filled to $\frac{65535}{96187} = 68 \%$ of the theoretical maximum speed of 1.5 Mbps, or 1.02 Mbps

By using the window scale option, the receive window size may be increased up to a maximum value of 1,073,725,440 bytes. This is done by specifying a one-byte shift count in the header options field. The true receive window size is left shifted by the value in shift count. A maximum value of 14 may be used for the shift count value. This would allow a single TCP connection to transfer data over the example satellite link at 1.5 Mbit/second utilizing all of the available bandwidth.

Network Settings

  1. Wired Node 1 in Transport Layer TCP Window Scaling $\rightarrow$ FALSE (by default) and Congestion plot set as TRUE.
  2. Application Generation rate $\rightarrow$ 10Mbps (Set Inter arrival time = 1168)
  3. Bit error rate (Uplink and Downlink) $\rightarrow$ 0 in all wired links
  4. Enabled Wireshark Capture in General Properties Wired Node 1 $\rightarrow$ Set as Offline
  5. Link1 & Link3 Propagation delay (uplink and downlink) $\rightarrow$ 5(Microsec) (by default)
  6. Change the Link2 speed $\rightarrow$ 10Mbps, Propagation delay (uplink and downlink) $\rightarrow$100000 (Microsec)
  7. Simulate for 100sec and note down the throughput
  8. Now change the Window Scaling $\rightarrow$ TRUE (for all wired nodes)
  9. Simulate for 100s and note down the throughput.

Results and Discussion#

Window Scaling Application Throughput (Mbps)
FALSE 2.5
TRUE 8.7

Throughput calculation (Without Window Scaling)

Theoretical Throughput = Window size / Round trip time = $\frac{65525∗8 \ Bytes}{200ms} = 2.62 \ Mbps$

Go to the simulation result window -> plots -> TCP Congestion Plot below Figures.

Figure4-31

Figure4-32

In Window Scaling False, the Application_Throughput is 2.5 Mbps less than the theoretical throughput since it initially takes some time for the window to reach 65535 B

Figure4-33

In Window Scaling TRUE, From the above screenshot, users can notice that the window size grows up to 560192Bytes because of Window Scaling. This leads to a higher Application_Throughput compared to the case without window scaling.

We have enabled WireShark Capture in the Wired Node 1. The PCAP file is generated silently at the end of the simulation. Double click on WIRED NODE1_1.pcap file available in the result window under packet captures, In Wireshark, the window scaling graph can be obtained as follows. Select any data packet with a left click, then, go to Statistics > TCP Stream Graphs > Window Scaling > Select Switch Direction.