Internet Speed Issue – Why TCP window size is matter

   June 9, 2009  Leave a comment

Using default TCP receive window size, 64 Kbytes (MS windows OSs, XP, Vista, 2003 server etc), not always is good if you have a high speed connections such as OCs and Gigabit Ethernet or extremely slow (?) connections such as Satellite link, 56 Kbps fractal T1s and so on. Because of TCP receive window size is not adequate for those network circumstance. TCP window scaling option (RFC 1323) will dramatically improve your TCP throughput, denoted download and upload speed. However, circuit condition should be under strict conditions as error free, no packet lost and no bottleneck. If a link condition is bad, TCP window scaling option makes worse TCP throughput. Let’s dig more info why the window size is matter and how we can tune it to get faster download/upload speed (TCP throughput)

 

I mentioned few times that default TCP receive window size is 64 Kbytes on most of MS OS (Later of Window NT and millennium version). Microsoft document said TCP window size is 64 Kbytes, but based on 16bit of TCP window field at TCP header, maximum TCP window size would be 2^16 -1 = 65535 bytes=65 Kbytes(the maximum unscaled window size). As you know TCP/IP was born in 1969 and it was designed and developed on WAN and LAN speed at that time. Most common Ethernet protocols were 10based-5, 10base-2 and later 10based-T. Yes, still we are using same TCP / IP header. It’s kinds of old for these days fast network environment. Even my home network is based on GigE ports. Most of the networks are 100 times faster than when TCP was developed. Well, WAN speed is not being moved fast than LAN. Still many people are using enhanced 56K modem links, T1s and below 3Mbps broadband link (of course upload is much slower than download). Then what is adequate TCP receive window size? For fast LAN and slow WAN.

Why TCP receive window size is matter?

Commonly TCP window size means a sender can send maximum amount of window size of data to receiver without acknowledge(confirmation) packet.

Let’s assume default TCP window size is 64 Kbyte on both testing devices at location A and B, Ethernet MTU is 1500 bytes, we are sending 100 Mbytes files from location A to B. Round trip time(RTT) is 50ms and transport link is under good conditions, no packet lost and bottleneck. Also, WAN trunk is big enough to send full size packets. Just simplify all the numbers and calculation. We just want to know how window size is affecting TCP throughput. (** please do not tackle me…… based on below numbers ^.^)

First, chop data to make size can be transferred.

100000000(bytes) / 1500(bytes) = 66666.66.

Roughly, 66667 packets can be sent to complete data transfer. However, as we assumed window size is 64 Kbytes. In every 43rd packet would be containing 1000 bytes instead of 1500 bytes. So, new number of packet to complete transferring data with TCP window size 64 Kbytes is total 67188 packets(65625 full packets and 1563 non-full packets).

 

TCP window size 64 Kbytes

100 Mbytes / 64 Kbyte = 1562.5

About 1562.5 times, sender has to wait acknowledgement packets. As we assumed RTT(Round Trip Time) is 50 ms, so one way trip time would be 25 ms. 

25 ms = 0.025 second x 1562.5 = 39.0625 seconds.

Per TCP Throughput Formula, TCP throughput with TCP window size 64 Kbytes and 50 ms RTT

(64 Kbytes x 8) / 50 ms =  512000 / 0.05 = 10240000 = 10.24 Mbps

100 Mbytes = 800000000 bits / 10240000 bits = 78.125 sec

Total transmission time for 100Mbytes with TCP window size 64 Kbytes is 78.125 sec. (included 39.0625 ms)

Check other article TCP Throughput Formula

If we have bigger TCP window size, the waiting time for acknowledgement (above case 39.0625ms) would be reduced. Per RFC 1323, we can use TCP window scaling option and it increase TCP window size up to 2^30.(1 Gbytes).

Okay, let’s change window size below (Applied same condition of previous testing)

 

TCP Window size 2^18 = 262144 bytes

Moment of stop sending and awaiting for Acknowledge packets
= 100 Mbytes / 262144 bytes =   381.47

Time for waiting Acknowledge packets
= 0.025 x 381.47 = 9.54 seconds.

TCP throughput = (262144 bytes x 8) / 0.05 = 41943040 = 41.94 Mbps

Total transmission time for 100 Mbytes data
= 100 Mbytes / 41.94 Mbps = 19.07 seconds (included 9.54 sec ACK waiting time)

 

TCP Window size 2^20 = 1048576 bytes

Moment of stop sending and awaiting for Acknowledge packets
= 100Mbytes / 1048576bytes =   95.37

Time for waiting Acknowledge packets
= 0.025 x 95.37 = 2.38 seconds.

TCP throughput = (1048576 bytes x 8) / 0.05 = 167772160 = 167.77 Mbps

Total transmission time for 100Mbytes data
= 100 Mbytes / 167.77 Mbps= 4.768 seconds (included 2.38 sec ACK waiting time)

 

TCP Window size 2^30 = 1073741824 bytes

Moment of stop sending and awaiting for Acknowledge packets
= 100Mbytes / 1073741824 bytes =   0.093

Time for waiting Acknowledge packets
= 0.025 x 0.093 = 0.0023 seconds = 2.3 ms

TCP throughput = (1073741824 bytes x 8) / 0.05 = 171798691840 =  171.79 Gbps

Total transmission time for 100Mbytes data
= 100 Mbytes / 171.79 Gbps =  0.00465 seconds = 4.65 ms (included 0.0023 seconds ack waiting time)

 

I guess now you have an idea, how TCP window size affects TCP throughput which is denoted download and upload speed.

How about UDP?

UDP doesn’t wait Acknowledgement packet from receiver, so you would get maximum bandwidth on your link. So sometime UDP testing is useful, when you verify what is maximum bandwidth or TCP throughput between location A and B. Even your ISP link. For example, if you have 3 Mbps download speed from certain server on DS3 link, but UDP testing gave you 43 Mbps download. It gives you information that no connection issue, but something else such as application or software issue. 

I don’t think everybody need to change TCP window size, because if connection is not reliable or congested on the path to get destination, it would give you worse TCP throughput due to TCP recovery function that missing or

corrupted packets need to be retransmitted. If you decide to use, see next article "How to use and configure TCP window scaling options"

 

Leave a Reply