|
Cable Modem
Guide
Digital Subscriber
Line
Satellite Guide
Share the Internet across
a home network
Why does tuning TCP Receive Window
improve throughput? TCP is a reliable communication protocol. As
a result, sender expects Acknowlegement (ACK) packets from receiver
to make sure packets are delivered to destination and are free of
errors. However, as sending one packet and waiting for ACK is rather
inefficient, a window is implemented. In this scheme, receiver advertises
its RWIN size during TCP connection setup and sender keeps sending
as many packets as allowed by receive window of receiver. In other
words, each packet sent closes the window a little and each ACK
received opens it up a little again. On a high bandwidth or high
delay (or both simultaneously) TCP connection, sender may transmit
a number of packets before the first packet reaches the receiver.
Even if the receiver were to send ACK immediately, it takes some
more time for the ACK packet to get back to the sender. To optimize
the throughput, the pipe must be filled at all times and to do this
sender should never stall waiting for ACK.This is only possible
if Receive Window is made sufficiently large. How large should the
TCP Receive Window be? Receive Window should be larger than bandwidth
delay product (also known as pipe capacity). For example, for 170ms
delay on a 768Kbps link, RWIN = 768000 bits/sec * 0.170 sec = 130560
bits = 16320 bytes. Note that if either available bandwidth or the
delay is doubled, RWIN would double as well. On LAN links the delay
is very small. Therefore, a small RWIN would be sufficient. However,
effect of insufficient RWIN size become particularly noticeable
on WAN links. Due to relatively small default RWIN size (8KB) Windows
95, 98, NT 3.51 and NT 4.0 throughput would suffer in above 768Kbps
connection during file transfer via FTP. Windows 2000 uses a more
realistic 16KB default for RWIN. However, that too would need to
be increased depending on pipe capacity. Well, that looks rather
simple but latency (delay) is actually not constant. It varies from
connection to connection and even during the lifetime of one connection
as some IP packets may follow different routes and the heavy load
on a router in the path may cause extra latency. Latency consists
of two parts; Propagation delay and transmission delay. Propagation
delay becomes significant for links established over satellites
and transmission latency becomes significant when the packets must
be forwarded over many routers. In addition routers usually introduce
more latency for larger packets than smaller packets. Generally,
heavy traffic in the pipe also increases transmission delays. To
determine delay accurately we actually need to measure downstream
and upstream delays separately because we receive large data packets
on downstream and generate much smaller ACK packets on upstream.
This measurement can be most effectively done on the sender side.
However, we can make an intelligent guess on the receive side by
using the PING tool to determine the round trip time for big (maximum
data packet sized) packets. Windows 95/98, Windows NT 3.51/4.0 and
Windows 2000 comes with a command line tool called "ping.exe". Open
a command (DOS) window and enter the following line: ping -f -n
10 -l 1472 host_or_IP Use (MTU - 28) as the parameter for -l option
(e.g. for ethernet use 1500-28 = 1472). See Microsoft KB article
Q159211 on using PING tool to determine MTU (see More Information
Section). Even though the article is targeted to Windows NT, this
portion of the article is general enough to apply all Windows OS
and the concept is applicable to other OS easily. In short, this
parameter should be the largest value that will NOT generate "Packet
needs to be fragmented but DF set." message. Large packet delay
measured using ping tool is the worst case delay, so it sets the
upper bound for RWIN. Most certainly normal delay will be smaller
as ACK packets used in return path will be much smaller and typically
delayed less. We may make a rough guess of typical delay by averaging
ping times of large (as above) and small (ACK sized) packets. For
ACK sized packets use 12 as -l parameter as in: ping -f -n 10 -l
12 host_or_IP Example: A 608/128Kbps DSL link with 200ms for maximum
sized and 100ms for small packet delays: RWIN(max) = 608000 * 0.200
= 121600 bits = 15200 bytes. RWIN(typical) = 608000 * 0.150 = 91200
bits = 11400 bytes. IS there a Windows TCP Send Window we can tweak?
There is not. In fact, the author of TCPTune has determined that
not only is the Windows TCP SendWindow not tunable, windows 98 at
least has problems with this send window.. which means that you
may not be able to upload as fast as you can download even with
a symmetric speed (SDSL) line. Information from the john navas site
|
