In previous articles about Windows NT Remote Access Service (RAS--see "Related Articles in Windows NT Magazine," page 126), I covered several aspects of this multifaceted NT component, including new features of NT 4.0 RAS and Dial-Up Networking (DUN), Virtual Private Networks (VPNs), and Registry tweaks to implement new or hidden functionality. But I haven't covered RAS performance. For this article, I've collected a few of my favorite RAS optimization techniques that enhance RAS performance on NT servers and workstations.
A lot of what I have to share relates directly to TCP/IP and IP-based RAS connections. The advent of the Internet and the widespread deployment of TCP/IP networks have made IP-based RAS connections the most common connections in modern NT networks. As a result, I'll cover both the configuration side of the RAS/DUN service and some specific protocol-related optimizations you can use with RAS.
Configuring RAS Devices
The first step in optimizing RAS is to ensure you optimally configure the dial-up adapters. Whether you're using a standard modem or ISDN terminal adapter, be sure you configure the device (and the communications port to which it's attached) to achieve maximum performance.
With any dial-up adapter, choose the highest Data Terminal Equipment (DTE) rate your modem supports. The DTE rate is the speed at which the computer sends data to your modem's serial (COM) port. Setting the dial-up adapter's DTE rate higher than its Data Communications Equipment (DCE) rate, the physical speed at which the device transmits data (the line rate), optimizes the device's performance. Optimizing the dial-up adapter in this manner guarantees that the computer will provide data to the device as fast as the device can process it. Setting the DTE rate higher than the DCE rate is important because most modern modems and ISDN terminal adapters employ data compression techniques to achieve effective transfer rates that exceed their rated speeds. You set the DTE rate of a COM port via the Baud Rate setting in the Ports applet in Control Panel. Screen 1, page 122, shows my settings for COM2.
To maximize the throughput of most dial-up adapters (including modems and ISDN terminal adapters using COM ports), set the DTE rate for the device to the highest setting recommended by the manufacturer. For 28.8Kbps and faster devices that communicate through COM ports, the optimal setting is usually 57.6Kbps or 115.2Kbps. You might have a port or modem driver that supports a higher number, such as 128Kbps, which reflects the highest possible speed of that device or port as reported to NT by the Unimodem driver or a custom serial driver.
The optimal DTE rate for a particular device depends on the particular COM port that the device uses, and specifically the universal asynchronous receiver-transmitter (UART) chip driving the port. The COM ports on all modern PCs come with 16550 or faster UARTs, which use 16-byte or larger first in, first out (FIFO) buffers, and support maximum DTE rates ranging from 38.4Kbps to 115.2Kbps. In addition, multiport serial boards often have dedicated application-specific integrated circuits (ASICs) or microprocessors that handle the serial I/O and allow for maximum DTE rates of 230Kbps or more. With fast external modems or ISDN terminal adapters, don't use communication ports that have older 8250 UARTs (which are slower and use no FIFO buffer) or 16450 UARTs (which have only a 2-byte FIFO buffer). These slower UARTs won't let you achieve the dial-up device's maximum speed, and will likely cause the port to become overrun and lose data during transmission. Typically, you won't have these problems with internal modems, because they contain UARTs that are fast and well-matched to the device's capabilities.
The Ports applet in Control Panel isn't the only place you can configure the maximum DTE rate setting for your dial-up adapter. You can also define this rate in the Modems applet in Control Panel for each dial-up adapter (under the General tab of the Properties dialog box for each device; you can reach this tab while editing a RAS/DUN phonebook entry). Therefore, I recommend that you set the Maximum Speed setting for each dial-up adapter to the highest possible rate. In most cases, this rate is equivalent to the one you set for the COM port earlier. The modem's Maximum Speed setting (as configured in the Unimodem driver for the device in the Modems applet) will typically override the DTE rate settings in the Ports applet for the communications port in question. For this reason, you might want to use the Ports applet default settings. The only potential disadvantage to this approach might be a case where you are using a non-Unimodem aware (e.g., DOS or Win 3.x-based) communications application. In this case, not setting the proper DTE rate in the Ports applet could limit the device's performance.
When setting DTE rates, first consult the device's documentation to verify the manufacturer's recommended settings; different manufacturers will have different recommended configurations for their products, and the documentation might contain clues that will help you obtain maximum performance from the device. You might discover additional commands or a specific initialization string that you can issue to the device to enable or disable specific performance-related features. You can place this information into the Extra Settings field of the Advanced Connection Settings dialog box, which you can access via the Advanced button in the Connection tab of a device's Properties dialog box. To take advantage of all the features of your dial-up adapters, be sure you have the latest version of the correct driver for each adapter you install.
Two noteworthy settings for improving the performance of your RAS device are available in the Ports applet in Control Panel. The first setting is Flow Control. Flow Control defines the method of handling data transfer between two communications devices when the DTE and DCE rates are different (which is usually the case) so that data is not lost. For most RAS devices, choosing either the default setting of None or selecting Hardware (i.e., Request To Send/Clear to SendRTS/CTS) flow control are typically the best choices. Hardware-based flow control means the hardware directly negotiates the flow of control. However, NT actually emulates hardware-based flow control in software. Although you might naturally suspect that this method is slower, my experimentation with different settings has shown little or no difference in regard to performance with different flow control settings selected. Leave the default settings of None or Hardware, because the Xon/Xoff setting (which is the standard for software-based flow control) is incompatible with binary transfers and therefore not recommended with dial-up adapters.
The other noteworthy setting is enabling FIFO buffers for the COM port attached to your RAS device (or created by the device, as with internal modems). Although the default in NT is to enable FIFO buffers whenever COM ports using them are detected, you still need to verify this setting. To view or change this setting, go to the Ports applet in Control Panel and choose Settings, Advanced to bring up the dialog box in Screen 2. With most dial-up adapters and communications ports, you obtain maximum performance and reliability when you enable FIFO buffer support.
Optimizing RAS/DUN Connections
Now that you've optimized the communications settings for hardware, you can tune the RAS configuration. I'll approach this subject first from the client side and then the server side.
First, when you're configuring DUN on a client to connect to a remote network running multiple protocols (e.g., an NT RAS server offering both IP and NetBEUI), try to limit the number of protocols, preferably to one. You'll greatly reduce the traffic flowing across the RAS connection and optimize the speed of the session. TCP/IP is usually the best protocol to use in routed networks or TCP/IP-only environments because doing so will not incur additional protocol overhead on servers or clients and will permit connectivity throughout the entire network. However, in terms of raw speed, NetBEUI is still usually the fastest LAN protocol for use with smaller networks (i.e., less than 200 users) and Microsoft RAS/DUN. Therefore, if your LAN is not connected to other networks or the Internet and is using NetBEUI as the primary or sole protocol, stick with this protocol for RAS, as well.
Next, consider implementing a Multilink Point-to-Point Protocol (MPPP--Multilink RAS in NT) RAS connection. A Multilink RAS connection lets you use more than one dial-up device simultaneously to achieve one, larger, virtual RAS connection. NT's RAS and the latest version of the Windows 95 DUN client support this functionality. To implement a Multilink RAS connection, you must install multiple devices at both ends. (The devices can be different types and speeds as long as they have a compatible counterpart at the other end of the connection.) In the DUN phonebook entry for the connection, select multiple adapters and enter the appropriate telephone number for each adapter to dial, as Screen 3 shows. Although this feature requires multiple RAS devices on the RAS server, it might be more attractive for increasing client bandwidth than upgrading the company's remote access infrastructure to support more expensive technologies such as ISDN. In addition, users connecting to the Internet via modem-based RAS connections can increase their bandwidth using Multilink RAS with their Internet Service Provider (ISP).
Many ISPs don't support Multilink RAS for analog connections, but several ISPs have recently started offering this service. The concept of Multilink RAS isn't very strange; after all, it's based on the technology used to bond the two 64Kbps bearer channels on ISDN terminal adapters. With modems, you use multiple physical modems rather than two bearer channels. (For more information about Multilink RAS, see "Related Articles in Windows NT Magazine," page 126.)
RAS Server Tweaks
In addition to establishing a Multilink RAS connection, you can experiment with a few other tips to increase RAS server performance. Specifically, you can tweak some of NT's Registry settings if the RAS servers on your network serve a large number of clients or act as gateways between very fast LANs and relatively slow RAS clients.
Before you experiment with any of the changes I mention in this article, do a full backup of the system and Registry. Also, be sure to benchmark your RAS performance before and after the changes to establish whether you derived a benefit. I know of two products that you can use to benchmark RAS connections to the Internet: TcpSpeed is available from Maximized Software as a freeware download from the company's Web site (http://www.maximized.com). Net.Medic is available from VitalSigns Software. Net.Medic is not freeware, but you can download a free trial version (http://www.vitalsigns.com).
Because of inherent speed differences in the connections between LAN resources and the remote RAS clients accessing them, your RAS server must buffer data going out to the RAS client on the slower connection. To establish the number of datagrams that you want to buffer per group (i.e., domain or workgroup) name, you need to adjust the MaxDgBufferedPerGroupName value under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Parameters\NetbiosGateway. This concept of buffering datagrams is especially important with regard to multicast network traffic intended for RAS clients. If you increase the MaxDgBufferedPerGroupName value (type REG_DWORD with a range of 1 to 255 datagrams and a default setting of 10), you can achieve better performance and improve reliability on slower RAS connections and RAS servers serving many clients simultaneously. In particular, you increase the reliability be-cause increasing the value reduces the number of potential dropped datagrams intended for the client (by default, the RAS Server will typically discard anything after the tenth buffered datagram).
Another Registry modification for RAS servers that relates to this disparity in speed between fast LAN resources and slow RAS clients is the amount of virtual memory NT uses to buffer NetBIOS session data for remote clients. The MaxDynMem value under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Parameters\NetbiosGateway specifies the maximum amount of virtual memory (paging file space) for buffering outgoing NetBIOS session data intended for each RAS client. This value is type REG_DWORD, has a range of 131,072 to 4,294,967,295 bytes, and has a default setting of 655,350 bytes. To minimize memory usage on the server, an NT RAS server allocates only about 64Kbps of physical memory for each RAS client. However, you can increase the total memory allocation per client using virtual memory in the paging file, up to the size you specify with the MaxDynMem value. You want to increase this value if the speed of the LAN or RAS client makes this value insufficient for RAS session data. When you increase the MaxDynMem value, you're increasing the amount of paging file space that will be used for each client session in buffering NetBIOS session data. As a result, you must leave sufficient paging file space to accommodate the size of the MaxDynMem value for all simultaneously connected RAS clients.
Finally, you can improve incoming packet performance for RAS servers and for RAS clients establishing Point-to-Point Tunneling Protocol (PPTP) connections. To improve the packet performance, locate the RxPacketWindow value under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasPptpe\Parameters\Configuration. This Registry value is of type REG_DWORD and defaults to a setting of 3 packets. It sets the maximum number of packets that either end of a RAS PPTP connection (i.e., server or client) can receive before an acknowledgment (ACK) packet must be sent to the other computer. NT automatically negotiates this value when you establish a new PPTP session and uses this value on both ends of the PPTP connection. You can increase the value on high-reliability WAN connections, including those for digital services such as xDSL, ISDN, Frame Relay, Cable Modems, and dedicated T1 lines to see whether it yields greater performance (I don't recommend increasing this value for analog-based PPTP connections, because they tend to be less reliable). This value is a global setting, and NT will use it for all PPTP connections to the server.
Optimizing TCP/IP-based RAS Connections
You might find the following tips for optimizing the TCP/IP protocol useful if you are establishing IP-based RAS connections over modems or ISDN terminal adapters. Specifically, if you're using TCP/IP over RAS connections, you'll want to understand how TCP/IP operates and whether the specifics of this operation are optimal for the speed of your particular RAS connection. Many Point-to-Point Protocol (PPP) RAS connections using TCP/IP are not well-optimized. Fortunately, you can take steps to improve performance.
Before establishing a TCP connection with a remote host, TCP/IP establishes the maximum packet size for the interface in question. To do so, the TCP/IP protocol first queries the underlying lower-level network drivers to establish the Maximum Transmission Unit (MTU) for the network adapter in use. MTU is the recommended transmission size, as determined by the type of media in use. For example, an Ethernet adapter would report a different MTU than a Token Ring or Fiber Distributed Data Interface (FDDI) adapter. Table 1 shows the default MTU sizes for various interfaces.
Intervening routers between the two hosts establishing the connection also report their MTU sizes, and NT automatically selects the largest MTU size supported by all routers. This action reduces the occurrence of packet fragmentation, which occurs when a router receives packets larger than the MTU size of the media in use; in this case, the packet must be fragmented by intervening routers and later reassembled by the destination host. Fragmentation increases protocol overhead and reduces performance. Subtracting the IP protocol overhead of 40 bytes from the reported MTU size gives you the maximum packet size for the connection, which is also known as the Maximum Segment Size (MSS). (Table 1 shows the default MSS values.) By default, NT automatically performs this greatest-common MTU size discovery. The minimum MTU size for any media type connected to IP routers is 576 bytes.
Although NT discovers a specific MTU size for a given path through the Internet, fragmentation can still occur on the way to and from the destination host because of the chaotic and dynamic nature of the Internet and its various pathways. In addition, NT determines the MTU size of a particular media type based on its rated throughput; Table 1 shows that PPP has the same MTU as Ethernet (1500 bytes, which means an MSS of 1460 bytes). However, Ethernet runs at 10Mbps, far less than the average RAS PPP connection of 28.8Kbps to 128Kbps. As you can see, PPP is not optimized for slower PPP connections; as a result, the MTU and MSS size that NT establishes for TCP traffic during a RAS session can be unnecessarily slow.
To remedy this situation and increase the network flow, you can experiment with modifications to two related values in the Registry. You'll find both values under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. The first value, EnablePMTUDiscovery of type REG_DWORD, specifies whether TCP uses a fixed default MTU of 576 bytes for off-subnet connections or attempts to detect the actual MTU between the two hosts. A value of 0 means TCP uses an MTU of 576 bytes for all connections to computers outside the local subnet. A value of 1 (the default setting) means TCP attempts to automatically discover the MTU of the path to a remote host.
If your primary connection to the Internet or a corporate WAN is a slow RAS-based connection, you might want to disable Path MTU (PMTU) discovery for TCP. By doing so, you will guarantee a 576-byte MTU (536-byte MSS) on all connections, which might improve performance. Making this change affects only off-subnet connections and doesn't affect TCP connections between the client machine and other machines on the same IP subnet.
The second Registry value you can modify in conjunction with the EnablePMTUDiscovery value is TcpWindowSize, which affects a change to the sliding window size for the TCP connection. A TCP sliding window is the amount of data that the sending host can transfer to the receiving host before the sending host requires an ACK from the receiver. You configure TCP sliding window size via the TcpWindowSize Registry value under the Tcpip\Parameters subkey. By default, NT automatically sets this value (of type REG_DWORD), which ranges from 0x0 to 0xFFFF (0 to 65,535 decimal) bytes. The TCP sliding window size equals either four times the MSS, or 8192 bytes rounded up to an even multiple of the MSSwhichever is larger. However, this calculation assumes that both of these values are smaller than 65,535 bytes; if they are larger, the maximum value of 65,535 bytes is used instead. For example, TCP over an Ethernet adapter by default establishes a sliding window size of 8760 bytes, which is the next multiple of its MSS rounded up above 8192 bytes (which is larger than four times its MSS, a value of 5840 bytes).
The multiples of the MSS factor are important because you want the TCP sliding window size to be an even multiple of the MSS used on the connection; an even multiple means more efficient transfers, because you don't have fragmentation. In this case, you have a slower RAS-based connection so you'll want the TCP sliding window size to match the manually-configured MSS of 536 (based on an MTU of 576). In this case, I recommend first trying a value of four times the MSS, or 2144 bytes.
As with EnablePMTUDiscovery, the TcpWindowSize value doesn't exist by default, so you will have to add it to the Registry. If you use a high-speed routed connection to the Internet or your corporate WAN rather than a dial-up RAS connection for IP connectivity, don't change this value because it can impair performance. Be sure to back up your system and Registry before making this or any other change. After making the change, benchmark the results to determine whether your RAS performance has improved with the new MSS and MTU size setting; if performance didn't improve, you can restore the modified settings back to their default values.
Although the EnablePMTUDiscovery and TcpWindowSize value modifications constitute global changes for TCP, you can set the MTU (and the MSS and TcpWindowSize) on an adapter-by-adapter basis. Typically, you want to let the network adapter driver generate this value automatically. However, you can manually set this value for your dial-up adapter in such a way that the change won't affect your other network adapters, which will probably be optimal with different MSS and MTU size values. As I mentioned before, the best value for slower RAS connections will often be the minimum MTU, 576 bytes. To make this change, you need to locate the correct Registry subkey related to the dial-up adapter in question (dial-up adapters appear as NDISWan interfaces in the Registry). This Registry subkey will be similar to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NDISWan#\Parameters\Tcpip. Here, <#> will be a number representing the dial-up adapter in question. It will be one of the adapters that has a Parameters\Tcpip subkey. If it is a dial-up adapter that receives a dynamic IP address, the IP address value under this key will be set to 0.0.0.0. You might have multiple adapters meeting these criteria, so be careful to select the correct one. To set the MTU for a particular dial-up adapter, add the MTU Registry value (of type REG_DWORD) and set the assigned data to 576 bytes to manually configure the MTU size. The MTU value can range from 0x0 to 0xFFFF (bytes).
Make Routing and RAS Servers Play Ball
If you have deployed a Routing and RAS (RRAS--formerly code-named Steelhead) server in a network using Open Shortest Path First (OSPF) routing, one issue might affect your network's performance. RRAS servers, by default, use an MTU size as specified in the Advanced Properties dialog box of the OSPF Configuration screen in the RRAS configuration utility. The problem lies in the fact that most OSPF routers use an MTU size based on the network media type in use (e.g., Ethernet, Token Ring, FDDI). As a result, the RRAS server might be using a different MTU size than other OSPF devices, forcing the other devices to fragment packets from the RRAS server, which diminishes performance.
I know two solutions to this problem: First, you can obtain the correct MTU size for your network and specify this value explicitly in the OSPF Advanced configuration dialog box. Second, you can obtain Microsoft's fix that addresses this RRAS problem. You'll find the fix at http://www.microsoft.com/communications/routing&ras.htm. (For more information about RRAS and OSPF routing, see "Related Articles in Windows NT Magazine.")
In this article, I looked at several tips and strategies you can use to increase the speed and reliability of RAS sessions. In future RAS articles, I'll explore other important aspects of RAS, including insights on deploying RRAS servers and using RAS with Microsoft Small Business Server (SBS).
Corrections to this Article:
- "Optimizing NT RAS" incorrectly stated that "Ethernet runs at 10Mvps, far less than the average RAS PPP connection of 28.8Kbps to 128Kbps." The correct comparison is "far more than."
