The Internet is, of course, a packet-switched communications system. It transmits datagrams from sender to ultimate receiver by enclosing them in transmission units along with destination address information (in a header), so they can be routed through available intermediary networks by the Internet Protocol (IP).

In dial-in connections, your TCP/IP stack (whose standard Windows program interface is called a WinSock) communicates through an asynchronous modem using Serial Line IP (SLIP), or the newer Point-to-Point Protocol (PPP). These protocols wrap each IP transmission unit (along with a check-sum, in the case of PPP) into a data frame. These software protocols allow your computer to simulate (to your TCP/IP-using application programs) the direct connection of your machine as an Internet node with its own IP address.

NOTE: For some people, this is a temporary IP address, which their access provider dynamically assigns to them from an address pool for the duration of their connection.

MTU: Each intermediary IP router on the Internet can handle a Maximum Transmission Unit. If requested to route a larger one, it will fragment it by breaking it up into smaller ones, each with its own IP header and a fragment of the original datagram, before sending it out on the network (where the next router could conceivably fragment them still further, if they exceed its MTU). These fragments must then be re-assembled at the receiving computer.

NOTE: Your MTU setting is an announcement of the maximum size IP transmission unit which your machine will accept from your access provider's communications server and the routers on his Local Area Network (LAN). There's no benefit to setting it to any value other than the one used on that LAN.

The bytes contained in these IP datagrams came from data segments, which were requested from the sender, and whose receipt is acknowledged by the requester, usually using the Transmission Control Protocol (TCP). Since they're often part of a larger transfer requested by a higher-level protocol (like the File Transfer Protocol, or the Hyper-Text Transfer Protocol), each segment is usually a fraction of a larger block of data (like a zip-file or a gif-image).

Each such (unfragmented) IP datagram contains a TCP data segment which is bundled with a TCP header. The TCP header contains information that enables the requester to account for every byte sent (by its individual sequence number) and to reassemble the segments in correct order into the total file.

MSS: The beginning of each TCP transfer includes an announcement by the TCP requester of the Maximum (data) Segment Size it will accept (along with the address to which the segments should be sent). The TCP sender may use any segment size it prefers that does not exceed this number. If this TCP segment size is small enough to fit (along with the TCP header and the IP header) into the smallest MTU encountered enroute, it will pass unfragmented.

Avoiding fragmentation has a major effect on file download speed. Keeping MSS small enough to do so, without making it so small that most of the bytes in a datagram are header overhead, is a major factor in tuning your winsock for maximum speed.

RWIN (Receive WINdow) is the limit set by the TCP receiver on the amount of data (hence, the number of TCP segments) the TCP sender is allowed to have outstanding on the Internet, pending his receipt of ACK(nowledgement of receipt) signals from the TCP receiver. An announcement of the available data window is the basic method of flow control used by TCP. Each time the TCP receiver ACKs the receipt of all bytes up to a particular sequence number, it also announces the available data window to the TCP sender . The value you specify for RWIN is the maximum value you will permit for the available window announcement. (The available window is reduced from the RWIN value by the number of bytes received but not yet processed).

NOTE: RWIN also corresponds to the size (in bytes) of the buffer your machine waits to fill with data segments before it attends to whatever other TCP transactions (like newsreading, or EMail) are occurring on other threads through the multiple logical sockets your WinSock has open while your download is in progress. This can affect the response delay you experience in mouse-clicking a URL on your web browser while an FTP file download is running in the background.

RTOmax is the maximum time a TCP sender will wait for an ACK before re-transmitting the segment. Consequently, your RTOmax will not affect the speed of your TCP data reception.

Van Jacobson "Compression" is actually a software technique for reducing the average amount of header data in each PPP (or SLIP) data frame. It takes advantage of the fact that only some header information changes from packet-to-packet in a long stream of packets sent from the same source to your IP address (like the TCP segments constituting an FTP transfer). The TCP/IP headers are re-constructed when the IP transmission unit is unwrapped from the PPP data frame, once it's in your winsock's RAM buffers.

NOTE: VJ header compression is not compression of the data being sent over the modem link. Hence, you should not assume it to be a replacement for the Lempel-Ziv-Welch (in V.42bis) or Huffman (in MNP-5) data compression done by your modem. What it will do, is reduce the effective percentage of the bytes in a PPP (or SLIP) data frame that are header overhead, leaving a greater percentage of the modem-to-modem transmission rate available for data.

Typically, the nominal TCP/IP header overhead of 40 bytes is reduced on average to well under 10 bytes per TCP data segment. Disabling VJ compression can reduce the modem-speed-limited transfer rate for uncompressible FTP downloads over a 28.8K bps modem link with MSS=536 from 3.2K bytes/sec to 3.0K bytes/sec. This is almost as large a reduction as dropping from a 28.8K bps modem connection rate to 26.4K bps.

This FAQ is available as a Windows Help® file for off-line viewing

Copyright© 1995 by Albert P. Belle Isle