|
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>TUNING MTU/MSS/RWIN:</H3> <P>Now that you have a solid PPP (or SLIP) layer, with no COM OVERRUNs or PPP FRAME CHECK ERRORs, you can tune for maximum speed. If you don't have a solid PPP (or SLIP) layer, don't even bother. TCP settings like <B>MSS</B> or <B>RWIN</B>, and IP settings like <B>MTU</B>, will <B>not cure COM OVERRUNs</B>. (See <A HREF="intro.htm">TCP/IP SETTINGS vs COM OVERRUNS.</A>) <P>The point of tuning TCP settings (MSS and RWIN) is to get the <B>most bytes of data per header</B> that (1) the TCP sender can send; and (2) will fit (along with 40 bytes of headers) in the smallest MTU along the IP routing path between TCP sender and TCP receiver (you), so as to <B>avoid fragmentation slow-down</B>. <P>Your access provider's MTU is a funnel through which <I>all</I> IP datagrams routed to you must pass. Since your IP Maximum Transmission Unit can't exceed the value used by your access provider's IP router, you might as well use that value for your MTU. <P><FONT SIZE=2><BLOCKQUOTE><B>NOTE:</B> Software that <I>remotely controls</I> your access provider's machine through a shell account always <I>relays</I> all downloads from that machine as TCP sender, after having him download the whole file over <I>his</I> TCP/IP connection. SLIP emulators like <B>SLiRP</B> do this; so does a normal SLIP or PPP connection with an HTTP or FTP <B>proxy server</B>. In this case, you should just match not only MTU, but also MSS and RWIN to him.)</BLOCKQUOTE></FONT> <P>The default MTU value for PPP is 1500 bytes at start of negotiation, so if you specify your <B>MTU=1500 for PPP</B> with any access provider, it should stay at that value. Many ISP's also use <I>Ethernet</I>s for their internal networks (<I>LAN</I>s) of servers, with a default MTU value of 1500. <P>Since SLIP was never standardized, any value is theoretically possible. Many Berkeley <B>UNIX</B> implementations of <B>SLIP</B> use the old <B>ARPAnet value of 1006</B>; all IP routers are now <I>supposed</I> to be able to handle at least the <B>IP default value of 576</B>; NetCom uses 556 on CSLIP (but 1500 on PPP); some systems use MTU values as small as 256. Your Internet Service Provider should tell you what value <I>he</I> is using for a SLIP connection. <P>Since an IP transmission unit has to allocate 20 bytes for its address header information, it can't hold more than MTU - 20 bytes of TCP data packet. Since TCP data segments are also packaged with 20 bytes for the TCP header information, your TCP Maximum Segment Size must be smaller than your IP MTU by at least 40 bytes. <P>You can never pass an unfragmented MSS greater than your access provider's <B>MTU - 40</B>. However, if his MTU is large enough, you can use any MSS that gives maximum throughput in FTP or HTTP downloads from remote TCP senders out on the Internet. The particular senders for which you optimize your MSS/RWIN should be those from which you most often get files or web pages. <P>The best speed for long streams of TCP segments (like from an FTP or HTTP download) is obtained with the largest MSS that will fit in the smallest MTU of all the IP routers along the route (to avoid IP fragmentation). The <B>Internet standard</B> default value of <B>MSS=536</B> (40 less than MTU=576) is a good starting point, as long as your ISP's MTU is at least 576. (With an ISP's MTU=552 or 556, you'd have to use MSS=512, another <I>de facto</I> standard.) <P>The <I>TCP ReceiveWINdow</I> limits the number of TCP data segments the remote TCP sender can launch onto the Internet before waiting for <I>ACK</I>nowledgement of receipt signals from your much slower machine. Since you don't want the TCP sender to transmit fragments or left-overs, you should ask him for an RWIN that equals an integer number of TCP data segments. Consequently, your <B>RWIN</B> should be set to an <B>integer multiple of</B> your <B>MSS</B>. <P>That multiple should be large enough to allow the sender to keep sending over a 56-to-1544 Kbps network during the entire period while waiting for the first <I>ACK</I> to come back from your 28.8Kbps machine (as long as your access provider has allocated at least that number of packet buffers on his IP router). That will <B>keep the pipeline full</B> for maximum speed. <P>Any larger value is, of course, not used by the sender, but may dictate the length of time your machine waits to fill buffers on a background file download before responding to your clicking on new links while web-browsing on another socket. So, don't overdo it. Try <B>RWIN=4*MSS</B> to start. Then experiment with 6 or 8 to see if you like the difference. <P><FONT SIZE=2><BLOCKQUOTE><B>NOTE:</B> The practical upper limit for RWIN is the number of IP packet buffers which your ISP's communications server has allocated to each dial-in connection. This should be at least 10, but could be as low as 3; see the section on Interpreting TCP Trace.</BLOCKQUOTE></FONT> <P>If you only want files or web pages on your access provider's server, use <I>his</I> MSS/RWIN settings. Since you are probably interested in other TCP senders, use <B>TCP Trace</B> to tune your settings for maximum throughput of those downloads you wish to do most often. <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="settings.htm"><IMG SRC="l_arrow.gif" ALIGN=BOTTOM></A><A HREF="trace.htm"><IMG SRC="r_arrow.gif" ALIGN=BOTTOM></A></P> <P><FONT SIZE=1>Copyright© 1995 by Albert P. Belle Isle</FONT> </BODY> </HTML>