What problem does the receive window solve?

TCPIP is a reliable network protocol where each packet sent is acknowledged by receiver, and if the sender doesn't get the acknowledge packet back within a certain timeout, then it retransmits the original packet. But it is inefficient to wait for the acknowledge packet from the receiver before sending the next packet. The Receive WINdow(RWIN) solves the problem of the sender constantly waiting for the receiver acknowledge.
How does receive window work?

The RWIN size specifies how much data, which can be sent to the receiver without getting an acknowledge from the receiver. This allows the sender to send several packets without waiting for acknowledge. It also allows the receiver to acknowledge several packets in one stroke.
Why is the size of the receive window important?

If the RWIN is too large, then the sender will spend a lot of time resending the entire RWIN every time packet loss is detected by the receiver. This is especially important if on a high collision network like a 100 Mbit Ethernet HUB. If Selective Acknowledgment (SACK) is enabled then it should lessen the downside of a too large RWIN. If the RWIN is too small, then the sender will be blocked constantly because it fills out the RWIN with packets before receiver is able to acknowledge that it has received the packets.
What is the proper size of the receive window?

The optimal RWIN is mainly dependent on two things:

Latency: The time it takes for a network packet to reach destination and get a reply back (Also known as ping time). If the latency is high and the RWIN too small, then it can allow the sender of data to fill out the RWIN before any acknowledge packet is returned. The latency for a connection is dependent on how quick the sender and receiver(and routers in between) are able to handle packets. If reaching the bandwidth limit of the physical line, then the latency becomes high. Bandwidth: The amount of data that can be sent within a given time. If the bandwidth is high and the RWIN is too small, then sender can fill out the RWIN too fast, before the receiver can acknowledge the received data. The max bandwidth for a connection is dependent on the lowest available bandwidth at sender and receiver(and routers in between). The max limit can also depend on the ISP capping, or by the receiving/sending application throttling the connection.

How to find the optimal receive window size with PING?

To use the PING (Packet InterNet Groper) tool to find the optimal RWIN Size, ping your ISP with the Max Transfer Unit(MTU) size (The -28 is because of the IP- and ICMP-Header which the PING tool adds.)

PING www.tiscali.dk -f -l <MTU-28> -n 10 Then insert the values of your connection in this calculation : Bandwidth(kbps) / 8 * Average Latency(MiliSec) = RWIN Size(Bytes) Then round up the RWIN Size to a multiple of the Maximum Segment Size (MSS) which is equal the MTU Size subtracted the size of IP Header (20 Bytes) and TCP Header (20 bytes + ? bytes depending of options like timestamp being enabled). So if your MTU Size is 1500 then your MSS is usually 1460 (1448 if timestamp is enabled).

Bandwidth

Latency MSS

Receive Window

kbps KByte/Sec

milisec bytes

bytes

How is the default receive window size calculated in Microsoft Windows?

Microsoft Windows tries to find the most optimal RWIN during the connection handshake. For most network types the following method will calculate a reasonable RWIN, so one doesn't have to configure it manually: 1. The initial connection request is created with a RWIN of 16384 bytes o Win9x/WinNT4 uses a RWIN of 8192 bytes o Win2k3 uses a RWIN dependent on media speed (Ignores latency): Below 1 Mbps: 8192 bytes 1 Mbps - 100 Mbps: 16384 bytes Greater than 100 Mbps: 65536 bytes o Windows Vista uses receive window scaling by default, and uses a default RWIN of 64K. o Windows 2008 uses Congestion Provider - Compound TCP (CTCP) that dynamically adjusts the RWIN. 2. When the reply to the initial connection is received the RWIN is adjusted: 1. RWIN is rounded up to a even multiple of Maximum Segment Size (MSS). 2. RWIN is adjusted to the larger of 4 times MSS, but not higher than 65536 bytes (unless Windows Scaling is enabled). If the GlobalMaxTcpWindowSize is set then it will be highest limit Note when creating a socket it is possible to overrule the default RWIN size using setsockopt with the socket option SO_RCVBUF. If the GlobalMaxTcpWindowSize is set, then it will limit the max size of the RWIN.

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"
Selective repeat

The most general case of the sliding window protocol is Selective Repeat ARQ. This requires a much more capable receiver, which can accept packets with sequence numbers higher than the current nr and store them until the gap is filled in. The advantage, however, is that it is not necessary to discard following correct data for one round-trip time before the transmitter can be informed that a retransmission is required. This is therefore preferred for links with low reliability and/or a high bandwidth-delay product. The window size wr need only be larger than the number of consecutive lost packets that can be tolerated. Thus, small values are popular; wr=2 is common