|
Server : Apache/2.4.62 System : FreeBSD fbsdweb2.web.rcn.net 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 User : www ( 80) PHP Version : 8.3.8 Disable Function : NONE Directory : /domains/ap.belleisle/~belleisl/tune_faq/ |
Upload File : |
<HTML> <HEAD><TITLE>AL's WINSOCK TUNING FAQ</TITLE></HEAD> <BODY BGCOLOR="#C0C0C0" TEXT="#000000" LINK="#0000FF" VLINK="#008000" ALINK="#FF0000"> <H3>YOUR TCP/IP SETTINGS:</H3> <P>The Internet is, of course, a packet-switched communications system. It transmits <I>datagrams</I> from sender to ultimate receiver by enclosing them in <I>transmission units</I> along with destination address information (in a <I>header</I>), so they can be routed through available intermediary networks by the <I>Internet Protocol</I> (IP). <P>In dial-in connections, your <I>TCP/IP stack</I> (whose standard Windows program interface is called a <I>WinSock</I>) communicates through an asynchronous modem using <I>Serial Line IP</I> (SLIP), or the newer <I>Point-to-Point Protocol</I> (PPP). These protocols wrap each IP transmission unit (along with a check-sum, in the case of PPP) into a data <I>frame</I>. 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. <P><BLOCKQUOTE><FONT SIZE=2><B>NOTE: </B>For some people, this is a temporary IP address, which their access provider <I>dynamically</I> assigns to them from an address pool for the duration of their connection.</FONT></BLOCKQUOTE> <P><B>MTU:</B> Each intermediary IP router on the Internet can handle a <I>Maximum Transmission Unit</I>. If requested to route a larger one, it will <B>fragment</B> it by breaking it up into smaller ones, each with its own <I>IP header</I> 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 <I>its</I> MTU). These fragments must then be re-assembled at the receiving computer. <P><BLOCKQUOTE><FONT SIZE=2><B>NOTE: </B>Your MTU setting is an announcement of the maximum size IP transmission unit which <I>your</I> machine will accept from your access provider's communications server and the routers on his <I>Local Area Network</I> (LAN). There's no benefit to setting it to any value other than the one used on that LAN.</FONT></BLOCKQUOTE> <P>The bytes contained in these IP datagrams came from <I>data segments</I>, which were requested from the sender, and whose receipt is acknowledged by the requester, usually using the <I>Transmission Control Protocol</I> (TCP). Since they're often part of a larger transfer requested by a higher-level protocol (like the <I>File Transfer Protocol</I>, or the <I>Hyper-Text Transfer Protocol</I>), each segment is usually a fraction of a larger block of data (like a zip-file or a gif-image). <P>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 <I>sequence number</I>) and to reassemble the segments in correct order into the total file. <P><B>MSS:</B> The beginning of each TCP transfer includes an announcement by the TCP requester of the <I>Maximum</I> (data) <I>Segment Size</I> 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. <P><B>Avoiding fragmentation</B> has a major effect on file <B>download speed</B>. 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. <P><B>RWIN</B> (<I>Receive WINdow</I>) is the limit set by the TCP receiver on the amount of data (hence, the <B>number of TCP segments</B>) the TCP sender is allowed to have outstanding on the Internet, pending his receipt of <I>ACK(nowledgement of receipt)</I> 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). <P><BLOCKQUOTE><FONT SIZE=2><B>NOTE: </B>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 <I>threads</I> through the multiple logical <I>sockets</I> your WinSock has open while your download is in progress. This can affect the <B>response delay</B> you experience in mouse-clicking a <I>URL</I> on your web browser while an FTP file download is running in the background.</FONT></BLOCKQUOTE> <P><B>RTOmax</B> is the maximum time a TCP <I>sender</I> will wait for an ACK before re-transmitting the segment. Consequently, your RTOmax will not affect the speed of your TCP data reception. <P><B>Van Jacobson "Compression"</B> is actually a software technique for reducing the average amount of <I>header</I> 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. <P><BLOCKQUOTE><FONT SIZE=2><B>NOTE: </B>VJ header compression is <I>not</I> compression of the data being sent over the modem link. Hence, you should <B>not</B> assume it to be a <B>replacement</B> for the Lempel-Ziv-Welch (in <B>V.42bis</B>) or Huffman (in <B>MNP-5</B>) <B>data compression</B> done by your <B>modem</B>. What it <I>will</I> 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. </FONT></BLOCKQUOTE> <P>Typically, the nominal TCP/IP header overhead of 40 bytes is reduced <i>on average</i> 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. <P ALIGN=CENTER><FONT SIZE=2><B>This FAQ is available as a <a href="../mtu_mss_rwin.html#BOTTOM">Windows Help® file</a> for off-line viewing </B></P></FONT> <P ALIGN=RIGHT><A HREF="../mtu_mss_rwin.html#TOP"><IMG SRC="contents.gif" ALIGN=LEFT></A><A HREF="overrun.htm"><IMG SRC="l_arrow.gif" ALIGN=BOTTOM></A><A HREF="tuning.htm"><IMG SRC="r_arrow.gif" ALIGN=BOTTOM></A></P> <P><FONT SIZE=1>Copyright© 1995 by Albert P. Belle Isle</FONT> </BODY> </HTML>