To determine the optimal TCP Receive Window, you can simply use one of the SG TCP Analyzer recommended values, or perform the following calculations:ġ. It is a much better method accounting for older routers and some wireless networks that don't work well with TCP Options (RFC1323), or large scale factors. When calculating an optimal RWIN value, one should try to use as high as possible unscaled RWIN values (usually the highest MSS multiple under 65535) and a smaller scale factor. A transmission can not exceed the RWIN / latency value. What does it mean ? The BDP, and the TCP Receive Window limit our connection to the product of the latency and the bandwidth. BDP is a very important concept in a window-based protocol such as TCP, as throughput is bound by the BDP ! The BDP states that:īDP (bits) = bandwidth (bits/second) * latency (seconds)īDP (bytes) = bandwidth (KBytes/sec) * latency (ms)īDP (bytes) = bandwidth * 8 (Kbits/sec) * latency (ms) It is the product of the available bandwidth and the latency (RTT). The Bandwidth*Delay product, or BDP for short, determines the amount of data that can be in transit in the network (just as RWIN). Considering the speed of light (186,000 miles per second), we can conclude that there is a minimum round-trip delay on a satellite connection of about half a second (500ms). Thus, that simple packet of data traveled at least 89,200 miles. Then, when the server sends its response, it has to travel the same distance back to the client, adding another 22,300 miles up + 22,300 miles down. The client's request (every packet) has to travel 22,300 miles to the satellite, then 22,300 miles down to the server. Let's examine a client computer communicating with a server over a geosynchronous satellite link. Data packets have to thravel through a number of high-traffic (sometimes congested) routers, and there is always the speed of light (or electricity for copper lines) as limitation, considering the huge distances of internet communication. In addition, however, let's consider the delay, or RTT(round trip time) of each data packet.Īny time a client computer asks a server a question, there is a RTT delay until it receives a response. The speed of every data transfer, like TCP is of course largely determined by the line speed.
Small initial/unscaled RWIN value is one of the shortcomings of Windows Vista's TCP Window "auto-tuning" as well.
that have problems coping with small unscaled RWIN values combined with high scale factors. It is a much better method for maximizing compatability with older routers (that don't work well with TCP Options), as well as some wireless networks, VPN endpoints, etc. When calculating an optimal RWIN value for broadband, one should try to use as high as possible unscaled RWIN values first (usually the highest MSS multiple under 65535) and a smaller scale factor. Thus, RFC1323 allows for a maximum TCP Receive Window of up to one gigabyte. Note that the scale factor is limited to 14 2^14=16384, and the maximum unscaled RWIN is 65535.
the actual RWIN value then would be: 64240 * 2^3 = 513920. The requested TCP Window Size is then the "Unscaled RWIN" multiplied by the "multiplier".įor example, let's assume an unscaled RWIN value of 64240, and a scale factor is 3. Compute the "multiplier", which equals two, raised to the power of our RFC1323 "scale factor".ģ. Start with the original 16-bit window size, let's call it the "Unscaled RWIN".Ģ. The RFC1323 RWIN byte can contain any value between 0 and 14, as follows:ġ. This limitation needed to be addressed, and in 19 added a "TCP Options" header extension, which allowed for expanding the maximum TCP Window size by adding another byte to act as a "scale factor" to the RWIN value. In the original DARPA TCP/IP standard, the TCP Receive Window (RWIN) was limited to 64K (65535), since there are only 16-bits in the TCP headers for the RWIN value, and 2^16=64K. The TCP Window is negotiated at the beginning of every connection during the TCP "handshake" stage. As such, this value is probably the single most important setting in tuning broadband internet connections. After sending that amount of data, the sender stops and waits for acknowledgement back from the receiver that it has gotten some of it. The TCP Window is the amount of outstanding data (unacknowledged by the recepient) that can remain in the network. This article is intended as a primer on some TCP/IP networking concepts and factors that determine an optimal TCP Receive Window.
0 kommentar(er)
