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 MSS or RWIN, and IP settings like MTU, will not cure COM OVERRUNs. (See TCP/IP SETTINGS vs COM OVERRUNS.)
The point of tuning TCP settings (MSS and RWIN) is to get the most bytes of data per header 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 avoid fragmentation slow-down.
Your access provider's MTU is a funnel through which all 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.
NOTE: Software that remotely controls your access provider's machine through a shell account always relays all downloads from that machine as TCP sender, after having him download the whole file over his TCP/IP connection. SLIP emulators like SLiRP do this; so does a normal SLIP or PPP connection with an HTTP or FTP proxy server. In this case, you should just match not only MTU, but also MSS and RWIN to him.)
The default MTU value for PPP is 1500 bytes at start of negotiation, so if you specify your MTU=1500 for PPP with any access provider, it should stay at that value. Many ISP's also use Ethernets for their internal networks (LANs) of servers, with a default MTU value of 1500.
Since SLIP was never standardized, any value is theoretically possible. Many Berkeley UNIX implementations of SLIP use the old ARPAnet value of 1006; all IP routers are now supposed to be able to handle at least the IP default value of 576; 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 he is using for a SLIP connection.
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.
You can never pass an unfragmented MSS greater than your access provider's MTU - 40. 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.
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 Internet standard default value of MSS=536 (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 de facto standard.)
The TCP ReceiveWINdow limits the number of TCP data segments the remote TCP sender can launch onto the Internet before waiting for ACKnowledgement 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 RWIN should be set to an integer multiple of your MSS.
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 ACK 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 keep the pipeline full for maximum speed.
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 RWIN=4*MSS to start. Then experiment with 6 or 8 to see if you like the difference.
NOTE: 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.
If you only want files or web pages on your access provider's server, use his MSS/RWIN settings. Since you are probably interested in other TCP senders, use TCP Trace to tune your settings for maximum throughput of those downloads you wish to do most often.
This FAQ is available as a Windows Help® file for off-line viewing
Copyright© 1995 by Albert P. Belle Isle