Please consider a donation to the Higher Intellect project. See or the Donate to Higher Intellect page for more info.

Optimizing Remote Access System Performance

From Higher Intellect Vintage Wiki
Jump to navigation Jump to search


Networking systems, particularly those including remote access, rely on complex and sometimes fragile interdependencies among their numerous component parts. Not only must each component of a remote access system work well by itself, but it must also integrate with the other components of the system to provide a cohesive whole that works well from end-to-end.

Traditional single-product evaluation and optimization, which may be adequate for computer system components that work mostly stand-alone, fall flat when applied to the components of a complex remote access system. So, while it may be sensible to consider the selection and installation of a CD-ROM drive or a large-screen monitor as an isolated decision, each component of a remote access solution must be considered with the rest of the system in mind.

Remote access systems demand a rare combination of expertise. Optimizing a remote access system requires knowledge of PC and Macintosh application and operating system software, of internetworking, and of telephony. That expertise, mixed with an overall system point of view, is a prerequisite for creating successful remote access systems.

What Must be Optimized?

From an end-user's point of view, the overall goal of remote access optimization is to create a system that comes as close as possible to making remote use "just like being there." All remote-node systems provide remote network access that is functionally similar to local network access, but only a system that is optimized from end-to-end can hope to provide remote access that truly approaches local access. That goal requires that a system designer focus on issues like end-user ease-of-use, performance, and breadth of protocol and application support.

At the same time, a remote access system designer must also consider the system administrator's point of view. Optimizing a system from an end-user point of view means little if it is too expensive or too unwieldy to install and maintain. From the system administrator's point of view, end-to-end optimization includes all of the end-user's issues, plus matters like security, scalability, and ease of management.

Vendor Choices vs. User Choices

A complete remote access system encompasses more than just the components provided by the remote access vendor. A complete system includes remote PC and Macintosh computers, application and operating system software, modems, telephone lines, and a host of other components in addition to the remote-access-specific servers and clients.

Choices made by the remote access vendor -- such as hardware design, protocol support, software integration, and so on -- have profound effects on the end-to-end optimization of a complete remote access system. These choices must be carefully considered when selecting a remote access vendor.

At the same time, choices made by the customer as he/she puts the whole system together -- such as type of remote computer, application software, or operating system -- may have equally profound effects on system optimization. In order to create a successful, end-to-end optimized system, the customer must first select the remote access vendor whose products best match his/her system requirements, and then put together the remaining pieces of the system with remote access optimization in mind.

This document discusses the most important optimizations to be made in a remote access system, including those that a vendor can make in its products and those that a customer should consider while putting together the remaining parts of a remote access system.

Optimizations by Component

A remote access solution can be divided into a few key components, each of which plays a part in putting together a complete system. This section discusses the role that each component plays in the end-to-end optimization of a remote access system.

Remote Computer

A computer used for remote access must function as a stand-alone system when it is not connected to any network, and as a full network node when it is dialed-in through the remote access system. It cannot rely on a high-speed LAN connection for storage of application software, nor is it merely a keyboard, mouse, and monitor surrogate in a remote control system. Therefore, the remote computer must perform adequately by itself, with enough CPU power, memory, and disk storage to run the end-user's chosen applications. Figure 1 shows a typical remote access configuration.


Figure 1. Typical Remote Access Configuration

Dialing-in through a remote access system can place an additional burden on the remote computer's CPU as well. Macintosh computers using Apple Remote Access (ARA) do not use their modem's built-in data compression, but instead perform compression in software. Since compression requires significant computational power, fast Macintosh computers perform noticeably better for remote access than their slower counterparts. For optimum remote access performance with the fastest modems, a remote Macintosh should have a 25 MHz 68030 processor or better.

Although remote access systems do not require that a PC perform compression in software, optimum remote access performance for PC systems requires at least a 25 Mhz 486 processor.

PC Serial Port

Serial port performance has an effect on the overall performance of a remote access system that far outweighs the attention it usually receives when choosing a remote PC. No amount of tuning can make a PC with an inadequate serial port interface perform well in a remote access system.

The burden placed on a PC's CPU by an interface is often inversely proportional to the maximum speed that interface can move data. Most high-speed interfaces, such as LAN cards, use sophisticated controllers that move large blocks of data with virtually no CPU intervention. Because the interfaces are so fast, sophisticated controllers are a requirement for the PC to keep up.

Serial interfaces, on the other hand, operate at relatively slow speeds, which often can be serviced directly by the PC's CPU. Until recently, most PCs were built with simple 8250 or 16450 serial controller chips that only minimally assist the CPU in sending or receiving serial data. With these chips, each time a character of data is ready to be sent or received, the CPU is interrupted from whatever it is doing, spends a few instructions figuring out why it was interrupted, and then sends or receives the next character as necessary.

By using an inexpensive serial controller chip, such as the 8250 or 16450, and relying on the CPU to service each character of data moving through the serial port, PC designers save the cost of a sophisticated serial interface controller. When serial port speeds were limited to 2400 or 9600 bits/second, that cost savings may have been appropriate. Improving modem technology has dramatically raised the speed that serial ports need to operate, to the point that 115,200 bit/second requirements are increasingly common. With an 8250 or 16450 serial controller, even a fast 486-equipped PC has trouble keeping up at those speeds.

When its CPU cannot keep up with its serial port, a PC experiences something called an overrun, when a new character arrives before the CPU has collected the previous one. Remote access data is sent in chunks called packets. If a character is lost from a packet because of an overrun, the entire packet is sent over again, usually not until a lengthy timeout has expired.

If the CPU is much too slow, overruns occur in almost every packet, and the remote access connection simply fails. If, however, CPU speed falls just short, complex interactions between the serial port, the CPU, memory managers, and other system software may cause intermittent overruns. In that case, the remote access connection may seem to work, but have intermittent problems such as sudden drops in speed, spurious loss of connections, and so on. Such inconsistent behavior is one of the most annoying problems faced by both end users and those who support them.

In addition to the differences in performance between serial controller chips, serial performance may also vary by operating system. For example, Microsoft Windows adds an extra layer of software for handling CPU interruptions, thus forcing the CPU to execute extra instructions each time it is interrupted to receive or transmit characters. On the other hand, DOS, as the simplest operating system, requires the least extra processing by the CPU each time it is interrupted. Therefore, a PC's maximum serial port throughput usually occurs when running DOS alone.

Even DOS is vulnerable to unexpected serial port slowdowns, however. The simplicity of DOS may also lead to less consistency because it provides no context for handling CPU interrupts. Therefore, some low-level DOS software -- particularly memory managers -- may turn off CPU interrupts for extended periods of time, during which time characters can be lost because the CPU is not aware that it must service them.

The need to support higher and higher serial port speeds has led to the use of a more sophisticated serial controller chip, the 16550A, in some PC designs. A 16550A serial controller can receive or transmit up to 16 characters without intervention from the CPU. Thus, with a 16550A serial controller, the CPU is interrupted much less frequently and moves more data with less effort. Most 16550A-equipped PCs can easily keep up with today's high-speed modems.

For optimum remote access performance with today's high-speed modems, a remote PC must have a sophisticated serial interface controller, most likely a 16550A. Given the heavy penalty of using a PC with inadequate serial port support as a remote access client, it makes sense to ensure that most, or preferably all, of the remote PCs being used with a remote access system are equipped with 16550A serial controllers. There are several ways to add a 16550A serial controller to a PC that does not already have one.

If the PC has a socketed 16450 serial controller, it can be replaced with a 16550A. Unfortunately, socketed 16450s are very rare. Usually, the 16450 is included with other controllers in a single, integrated chip and cannot be easily replaced.

The next option, if the PC has an ISA expansion bus, is a 16550A-based serial controller card. Such a card can be installed in a PC, the PC's on-board serial interface disabled, and the serial controller card configured in its place.

For a laptop with a PCMCIA expansion connector, a PCMCIA modem is likely to work well. Almost all PCMCIA modem cards have 16550A serial controllers on board. Most modern laptops include PCMCIA support, and PCMCIA modems are both inexpensive and convenient.

Some older laptops are either not expandable or use a proprietary expansion bus for which 16550A-based modem cards are unavailable. Such machines cannot be upgraded to a 16550A serial controller, and are not well suited to use in a remote access system.

Application Software

The choice of network applications may have more effect on remote access performance than any other issue. Because remote access systems provide inherently lower data throughput than LAN-only systems, it is critical that applications minimize the amount of data sent over the network. A network application that is not optimized for remote access may send so much network data that it cannot possibly perform well over a remote connection.

Some network applications are designed to "think" of the network server as just another file system, with plenty of throughput and only minor cost for moving large quantities of data to and from the server. Such a model simplifies application development and exacts only a modest performance penalty for its simplicity, so long as it is used on a high throughput LAN such as Ethernet or Token Ring. The first wave of networked applications to show up in the PC market were designed primarily on this "network-as-file-system" model.

Unfortunately, applications built on the "network-as-file-system" model often move far more data than necessary to perform a task. To get the data that it needs, a network client built on this model uses the file system to read a large block of data and then searches through it for the portion that is relevant. Most of the data that is moved across the network by such applications is discarded soon after it arrives. When bandwidth is at a premium, as it is in a remote access system, such excess data movement drastically reduces performance.

A new generation of network applications emerged after the first wave, built on the "client/server" model. In the client/server model, the network client and the network server are both intelligent systems capable of finding and manipulating data themselves. To get the data that it needs, a network client built on the client/server model generates a request for that data, which it sends across the network to the server. The server processes the request, finds the relevant data, and sends it back to the client over the network. Only the data that the client needs is actually sent over the network.

As an example that illustrates the differences between the two models, imagine a network-resident database containing 500 records, each one 1000 characters long. To find an individual record, a "network-as-file-system" application must load records across the network, searching until it finds the right one. A particularly inefficient search might move every record in the database -- up to 500 Kb in this example.

To find that same record in the client/server model, the client tells the server exactly which record it wants; the server finds that specific record; and then the server sends that record back to the client. Only the record that the client cares about -- 1 Kb in this example -- moves through the network.

Despite the tremendous advantages for remote access of client/server applications, existing "network-as-file-system" applications -- custom database applications, for example -- may be expensive or impossible to replace. If so, a remote-control system can be layered on top of the standard remote-node based remote access system, without losing any remote-node functionality. Figure 2 shows a typical remote-node remote-control configuration.


Figure 2. Remote-Node/Remote-Control Configuration

A network-based remote control package such as Symantec's pcANYWHERE/LAN can use the remote access link to make a network connection and take over a PC on the same LAN as the "network-as-file-system" server. The large data movements of a "network-as-file-server" application are thus confined to the LAN, and only user interface information (characters and keystrokes) need travel over the remote link.

Similarly, an application server such as Citrix' WinView can be located on the same LAN as the "network-as-file-system" server, again making use of the remote access link to move only user interface data.

Application Partnerships

Partnerships between remote access and application vendors can greatly improve the performance of an application over remote access. For example, Shiva and Lotus worked together to optimize cc:Mail Mobile for use in remote access systems, making dramatic gains over the remote access performance of the original LAN-based cc:Mail.

Shiva has also worked with Lotus to provide an improved remote access solution for Lotus Notes. Remote users are able to access all of the Notes servers on a network with a single telephone call, and Notes applications that use doc links can be designed for remote, as well as local-access.

Remote Computer Operating System

The simplicity, flexibility, and ease with which an end-user can establish a remote access connection is determined largely by interactions between the operating system, network operating system (NOS) client, and remote access client software.

In an optimized remote access system, end-users should face no restrictions on the environment from which they can establish a remote access connection. For example, it should be possible to establish a remote access connection in DOS, switch to Windows, and still make use of the remote access link. Conversely, it should be possible to establish a connection in Windows and use it in DOS.

Making connections from Windows is generally the simplest, easiest way for a PC end-user to make use of a remote access system; so for optimum end-user usability and convenience, the remote access system should include client software that can establish and end remote access connections from either DOS or Windows, and the NOS client must either be able to load and stay resident without requiring a connection, or must be able to be loaded on demand in either DOS or Windows.

Until recently, incompatibilities between Novell's NetWare shell and remote access made it impossible to use Windows to establish a remote access connection for NetWare. The original NetWare shell, which is a DOS terminate-and-stay-resident (TSR) program, expects to attach to a server at startup. The implied assumption -- that a server is reachable when the shell is launched -- is generally true for a PC directly attached to a LAN, but often not true for a remote access user.

The original versions of the NetWare shell cannot load and stay resident without attaching to a server. Since the shell needs a network connection to attach to a server, the original shell cannot be run until the remote access connection is established. Since the original NetWare shell must run after a remote access connection is established and before Windows is started, it forces the remote access connection to be established before Windows can start.

Novell has produced new versions of the NetWare shell for its Virtual Loadable Module (VLM) network client architecture. The new versions are designed to work with a PC that is detached from a LAN. VLM versions of the shell load and stay resident even if they cannot attach to a server at startup. This makes it possible to load the NetWare shell, start Windows, then establish the remote connection and attach to a server sometime later, without ever returning to DOS.

NOTE: The VLM architecture and the new versions of the NetWare shell work with both Version 4.x and earlier NetWare servers.

Network clients that are more tightly integrated with Windows, such as Microsoft's Windows for Workgroups, allow the NOS client to be loaded on demand in Windows, thus negating many of the issues that arise with the NetWare shell.

An optimized remote access system includes client software that can establish remote access connections from either DOS or Windows, and NOS clients that either load and stay resident without requiring a connection (like the VLM version of the NetWare shell) or can be loaded on demand in either DOS or Windows (like Windows for Workgroups).

Windows Dial-In

Remote access solutions from Shiva integrate Novell's NetWare clients and protocols, including the NetWare shell and VLMs. Shiva's remote access client works with Novell's VLM-based NetWare shell to provide double-click remote access directly from Windows to a NetWare LAN.

Network Operating System

The protocol implementation used by the NOS can also play a key role in determining the overall performance of a remote access system. The speed of a remote access system is primarily a function of the system's raw capacity to move undifferentiated data (bandwidth) and of its ability to use that bandwidth efficiently by keeping it filled with useful information. The NOS protocol implementation bears a large responsibility for the efficiency with which available bandwidth is kept filled with useful information.

Data typically moves in networking systems by a 2-way interaction between computers, in which one computer asks the other for some data and then sends back a confirmation when it receives a response. This interaction can potentially cause inefficient use of available bandwidth due to protocol design or implementation considerations.

Inefficiencies due to the 2-way interaction in networking protocols can come from several sources. The most important of these are delays and retransmissions.

Significant delays can be introduced into remote access systems, particularly by transmission line idiosyncrasies -- satellite transmission is a common culprit -- or by intermediate devices such as bridges or routers. Delays hurt performance by leaving gaps during which one system waits for a response from the other, and therefore no useful data flows.

Protocol implementations that can have only a single packet of unacknowledged data outstanding are particularly vulnerable to delay-induced performance degradation. After each packet of data is sent, the system waits for it to be acknowledged before sending another. Any delays cause dead time when the available bandwidth is not being used, hurting performance.

Basic implementations of the IPX/SPX protocol usually allow only a single packet outstanding at one time. By contrast, the basic data transfer protocol in TCP/IP is an example of a "sliding-window protocol." Sliding-window protocols are designed to keep a connection filled with data despite delays by continually sending the next packet of data before the previous one has been acknowledged.

Novell has developed an implementation of its IPX protocol, called packet-burst IPX, that allows IPX-based network applications to send multiple packets for each acknowledgment. Packet-burst IPX must be implemented in the NetWare client and as a server NetWare Loadable Module (NLM). The VLM version of the NetWare client includes packet-burst IPX.

In remote access systems that are subject to particularly large delays, such as satellite-based communications, a sliding-window protocol or a multiple-packet-per-acknowledgment implementation like packet-burst IPX, is necessary for optimum performance. For ordinary connections using modems and land lines, such protocols offer less of an advantage.

Data retransmission due to timeouts or data errors in a remote access system can cause catastrophic speed losses or even complete failure. When a piece of data is lost due to data corruption, the system waits a fixed amount of time and then requests that piece of data again. Retransmissions due to genuine data loss hurt performance because of gaps during which the link is empty, while the requesting system waits the appropriate timeout period and then re-requests the missing data.

Data loss in a remote access system is most likely to occur in the modem connection or in the PC's serial port and should be minimized by using error correcting modems and high-performance serial ports.

Retransmissions can also occur if the requesting system's timeouts are too short, causing it to re-request packets before they have a chance to legitimately arrive. In this case, the same packet is transmitted multiple times, congesting the link and further slowing down the arrival of legitimate data. Retransmissions due to timeouts may create congestion that feeds on itself until it eventually causes a remote access connection to fail completely.

Some versions of NetBEUI-based network operating systems, such as Windows for Workgroups and LAN Manager, are particularly susceptible to timeout-induced retransmissions. A remote access vendor should provide specific recommendations for modifying timeouts in a NetBEUI-based network OS.

For most AppleTalk-based Macintosh software, timeout settings are left to the applications themselves, rather than being handled consistently by the network OS. Therefore, retransmissions due to timeouts may be a problem for some Macintosh applications but not for others. Sophisticated remote access servers can eliminate the problem by recognizing and removing timeout-induced requests before they cause duplicate packets to be transmitted unnecessarily.

The last big issue in determining a protocol implementation's effect on remote access performance is the overhead a protocol adds to each packet of data. Every networking system must include extra data with each packet so that the system knows what to do with that packet. Each layer of a networking system adds packet overhead, which may add up to a significant fraction of the packet's total size. Efficiency is low when packet size is small relative to its overhead. Efficiency is high when packet size is large relative to its overhead. Since overhead is the same regardless of packet size, big packets are usually more efficient than small ones.

For best performance, protocol implementations should use the largest packets possible. Novell's packet-burst server NLM allows NetWare to use packet sizes that approach the maximum size for the LAN media between the NetWare client and server. Use of large packets reduces packet overhead as a percentage of the total amount of data being sent, and thus makes more efficient use of the available bandwidth in a remote access system. Use of large packets provides significant, noticeable speed improvements over normal packet sizes in almost any remote access system.

Windows for Workgroups Tuning

Shiva and Microsoft worked closely together to tune Windows for Workgroups for remote access. Shiva's remote access products are the only solutions in the market that provide complete Windows for Workgoups remote access.

Remote Access Client Software

The remote access client software is an end-user's primary link into the remote access system, and, as such, it is the prime determinant of a remote access system's ultimate ease-of-use. The remote access client is also critical to compatibility with a wide range of protocols and equipment, and a major factor in the system's overall speed.

A remote access system should support any standard or de-facto standard remote access client software that is available for an operating system. Macintosh users should be able to use Apple's standard remote access client, called Apple Remote Access. (Refer to Using Apple Remote Access for more information.) UNIX users should be able to choose any standard Serial Line Internet Protocol (SLIP) or Point-to-Point Protocol (PPP) implementation. Because Windows and DOS do not yet have standard remote access clients, the remote access vendor must supply them. (Refer to the ShivaRemote Dial-In User's Guide for the PC for more information.)

A remote access client performs two major tasks: establishing and terminating the remote access connection, and sending/receiving network traffic across the network link. It is helpful to think of the remote access client as having two parts, a "dialer" which manages the link, and a "driver" which interfaces with the network protocol stacks and the serial port to send and receive network data.

The remote access client's dialer is crucial to end-user ease-of-use and also largely determines the range of data transmission equipment with which the remote access system can be used. For PC-based end-users, the remote access client should offer both DOS and Windows dialers, so that users can easily establish connections in either environment; a Windows dialer is especially important for end-user ease-of-use.

The dialer also determines the range of different modem types, telephone connections, and security systems that are usable within a remote access system. A dialer needs to have flexible modem handling that makes it easy to add support for new types of modems or other data communications equipment such as Integrated Services Digital Network (ISDN) terminal adapters. The dialer also needs built-in support for a wide variety of existing modems, terminal adapters, and other data communications devices.

A dialer must also be able to deal with complex connection sequences. Entering credit card numbers, passing through packet networks such as X.25, and navigating sophisticated security systems are all common roadblocks to establishing a connection. Such roadblocks require either a dialer with flexible scripting, which can be programmed to navigate a complex connection sequence automatically, a manual mode that allows the user to navigate the connection directly, or both.

The remote access client's driver is a key factor in the number of different protocols and protocol implementations that a remote access system supports. End-user application needs are more and more likely to require that a remote access system support multiple protocols. Therefore, it is critical that a remote access client work well with a wide variety of protocols.

For PC-based systems, a minimum set of supported protocols should include Novell's IPX, which is the native protocol for NetWare; TCP/IP, widely used in UNIX systems and client-server databases, but also becoming a standard for many other applications; NetBEUI, used for LAN Manager and Microsoft's Windows for Workgroups; and LLC/802.2 for IBM LAN Server and host connectivity. For Macintosh computers, the protocol group is somewhat simpler -- the combination of AppleTalk and TCP/IP covers almost all Macintosh applications. UNIX systems are primarily covered by TCP/IP support.

Not only must the remote access client support multiple protocols, but it must support them simultaneously. For example, a user may need to use an electronic mail package that uses the IPX protocol and a custom client/server database application that runs on TCP/IP. The remote access client should never force a user to disconnect and reconnect with a different protocol to switch between applications.

In addition to supporting multiple protocols simultaneously, for full compatibility with the maximum number of protocol implementations, a remote access client must support the major PC network interface driver standards: ODI and NDIS. Since PC system memory is scarce, the driver should also take up as little system memory as possible.

The remote access client, in partnership with the remote access server software, plays an important part in optimizing a system for speed. Issues such as header compression and broadcast suppression, in which the client participates, are explained in the "Remote Access Server Software" section.

Client Partnerships

Shiva and Microsoft have announced a partnership to provide multiprotocol, Point-to-Point Protocol (PPP)-based remote access capabilities for the next generation of Windows (code named Chicago). Shiva also has a development partnership with Apple Computer to create a next-generation Apple Remote Access (ARA) client that operates over the industry standard PPP.

OS Partnerships

Through an OEM and joint development relationship with IBM, Shiva products are optimized for remote access to Systems Network Architecture (SNA) environments including 3270 and 5250 emulation.

Shiva works closely with the leading TCP/IP for PC vendors, including Novell, FTP Software, Sun Microsystems, and NetManage to ensure that their protocol solutions work well for remote access. Additionally, UNIX remote users can dial in to Shiva's LanRover family of remote access servers via PPP or SLIP.


Remote links have only a fraction of the bandwidth available to LANs. Networking applications are typically designed to work best at LAN bandwidths and are noticeably slower over remote connections. To minimize the difference between local and remote performance, it is critical to use the fastest modem technology available for remote connections.

Almost all modems sold today use data compression techniques to improve throughput. Claims of 4-to-1 data compression are for best-case, highly compressible data, and probably do not represent realistic, real-world performance expectations. Compression also exacts a small penalty by introducing delays as data is collected into compressible blocks rather than being sent in a continuous stream. Therefore, compression, while valuable, is not a substitute for raw, uncompressed throughput.

A V.32bis modem with a 14.4 Kbit/second data stream and 4-to-1, best-case compression may "talk" to the remote computer's serial port at 57.6 Kbits/second, but with real-world data and correspondingly real-world compression, its actual throughput is likely to be about half that. An ISDN terminal adapter, on the other hand, may also talk to the remote computer's serial port at 57.6 Kbits/second, but it does not rely on compression, and thus its real-world throughput probably doubles that of the modem.

For the sake of reliability and consistency, the modem must also be able to respond gracefully when telephone conditions are not good enough to support a maximum speed connection. Modems should support "fall-forward" and "fall-back" which allow them to monitor error counts and either drop the connection speed when error counts get too high, or increase connection speed when error counts drop back down.

For laptop use, PCMCIA modems are better than external modems because they have a high-speed bus connection to the system and usually contain appropriately fast serial ports with 16550A support.

The requirements for modems attached to a remote access server are a superset of the requirements for the remote PC modem. Additionally, the modems attached to the server must be able to interoperate with every kind of modem the system's users plan to dial-in with, at the maximum speed the remote modem can support. Both modems in a remote access connection must be able to perform at the desired levels, as the connection works only as well as its slower half.

The server modems for an enterprise remote access solution, which might have large numbers of ports, need to be rack-mountable, as compact as possible, and should be manageable as well.

For the simplest, most manageable enterprise solution, modems should be integrated directly into the remote access server. Integrated modems save space, avoid disorderly, unreliable cabling between the server and a bank of modems, and can be managed with the same tools as the server itself.

Telephone Connection

Today's high-speed modems are remarkably tolerant of difficult telephone line conditions, but nonetheless, telephone connections can have all sorts of problems -- among them noise, distortion, and echoes -- any one of which can drastically reduce either the reliability or speed of a modem link. Telephone connection trouble is one of the most annoying problems because it is rarely consistent and often is extremely difficult to find.

If a user is off site and encounters an unusable telephone line, there really is not much to be done about it. Calling at a different time of day may help, because varying loads on the telephone network can cause calls between the same two endpoints to travel very different paths.

If a user has a problematic telephone line into his/her house or some other fixed location, it may be necessary to order a data-quality telephone line, particularly in rural or high-interference areas.

In many urban areas, switched digital links, which avoid the unreliability and inconsistency of analog modem connections, are now available. ISDN and Switched56 service are fast becoming viable options for remote users who dial in from fixed locations. In addition to offering more reliable service than analog connections, switched digital links provide superior performance. An optimized remote access system should take advantage of switched digital connections wherever they are available.

Wireless remote access is also a viable option for mobile users. Functional remote access connections can be made using cellular modems over analog cellular telephone networks, although performance and reliability do not match up with that of wired connections. The advent of digital cellular data transmission offerings, such as Cellular Digital Packet Data (CDPD), will enable wireless remote access with performance and reliability similar to that of wired digital connections. Such services should become widely available in the next few years.

Remote Access Security

Optimizing security in a remote access system requires tradeoffs among level of security, complexity, manageability, cost, ease-of-use, and myriad other factors. Each network administrator makes those tradeoffs differently, so there is no single optimal solution for remote access security. There are, however, optimization strategies that make sense for certain specific categories of remote access systems.

A small, relatively simple remote access installation with straightforward security requirements should place as few demands on its network administrator as possible. Therefore, the optimal security system for such installations is simple and requires minimal initial set-up time. Simplicity and low start-up effort are best obtained by using the remote access server's internal database to store authentication and authorization information.

A remote access server's internal database should be simple, easy to use, and require very little up-front time to get working. In addition to storing user names and passwords, an internal database should also store a configurable set of attributes for each user, such as dialback, maximum connection time, IP address, and server administration permissions. The database may also add security options such as a user lockout feature that disables a user name after a number of unsuccessful log-in attempts.

Since each remote access server maintains its own copy of an internal database, it is imperative that the database can be replicated quickly and easily for multiple servers. Ideally, user information in a set of remote access servers should be manageable as if they comprise one integrated system.

For larger-scale remote access systems with straightforward security requirements, it makes sense for a network administrator to trade lengthier initial setup for long-term time savings in managing the system. Large system security is best optimized by integrating the remote access system's authentication and authorization with a robust, centralized authentication service that serves the network as a whole.

The most widely used centralized authentication scheme is NetWare's Bindery service, which provides user/password management for local access. A remote access server that can authenticate users via the Bindery allows network administrators to maintain a single database of users for both remote and local access.

The choice of a centralized authentication and authorization database is not tied to the protocol or operating system needs of end-users. For example, the NetWare Bindery can authenticate Macintosh users who use AppleTalk exclusively.

The optimum security system for a remote access system with stringent security requirements is likely to be external to the remote access server and provided by a vendor that specializes in security systems. A remote access server should permit simple and seamless integration of external security systems to give the most flexibility in security options, allowing the system designer to choose from a wide variety of security systems designed and built by companies that specialize in security.

The most popular high-security systems use techniques that fall under the heading of "tokenized" security. With a tokenized security scheme, users must know their Personal Identification Number, or PIN number and also have a token in order to prove their identity. Tokens are serialized, credit-card sized electronic devices that perform some sort of calculation to prove their existence. Sophisticated remote access systems provide seamless integration with the most popular tokenized security systems, such as SecureNet Key from Digital Pathways and SecurID from Security Dynamics.

Shiva's Security Offerings

Shiva's remote access products permit centralized authentication via the NetWare Bindery. Shiva's servers also offer an internal authentication database that can be easily managed across multiple servers. Shiva's LanRover family is designed to integrate seamlessly with third-party security products such as SecureNet Key from Digital Pathways and SecurID from Security Dynamics.

Remote Access Server Hardware

Ideally, the hardware used for a remote access server should be designed for, tested for, and optimized for remote access. Force-fitting remote access into a general- purpose hardware platform like a PC is likely to result in compromises of speed, form-factor, reliability, and convenience.

Performance of remote access server hardware is primarily determined by its ability to move data through its serial ports without much attention from the CPU, and by the CPU's ability to perform the routing, filtering, etcetera, that it must do without adding undue delays as it forwards packets. Remote access server hardware should be optimized for serial port throughput and general CPU power.

The remote access server must be highly reliable and efficient. Therefore, a remote access server with few moving parts, such as floppy or hard disk drives, has a substantially reduced risk of breakdown. Server software and configuration should reside in solid-state, non-volatile storage, such as battery backed up static RAM, or flash memory, and should be upgradable via network downloading.

The remote access server should also have an appropriate form-factor for its planned use. Remote access systems that provide enterprise support -- with large numbers of users and the need to fit many remote access ports in a small space -- should be rack mountable, with high port densities. A workgroup remote access system, on the other hand, is often best served by compact, tabletop server hardware.

Convenience can play a large role in the on-going costs of managing a remote access system. The on-going management of modems, modem cables, and telephone line interfaces can be costly. A remote access server that offers integrated, internal modems reduces the headaches that come from installing, maintaining, and managing separate banks of server and modem ports.

Integrated Modems

Shiva's LanRover/PLUS multiport remote access servers support modular internal modems, as well as external modems and ISDN terminal adapters.

Remote Access Server Software

Perhaps the most important thing to look for in a remote access server is versatility, which is primarily a function of the server software. Since the remote access server makes use of scarce resources (modems and telephone lines) it should support as many uses of those modems and telephone lines as possible. This document focused on end-to-end optimization of single-user dial-in access, but for optimal use of modems and telephone lines, the remote access server should support shared dial-out and LAN-to-LAN connectivity as well. (Refer to the LAN-to-LAN Administrator's Guide, Shiva Dial-Out User's Guide for the Macintosh, and the Shiva Dial-Out User's Guide for the PC.)

The remote access server should provide a single point of remote access for PC, Macintosh, and UNIX users. Therefore, as with the client software, it is critical that the remote access server support a wide variety of protocols, with a minimum set for PC-based systems including IPX, TCP/IP, NetBEUI, and LLC/802.2. For Macintosh computers the combination of AppleTalk and TCP/IP covers almost all Macintosh applications, and UNIX users need TCP/IP almost exclusively.

One particularly tricky issue is support by the software for an assortment of addressing schemes. Addressing schemes are different for each protocol. Some protocols, such as AppleTalk, use addresses that are completely dynamic and require little or no administrative or user intervention. In others, such as TCP/IP, address administration is a critical issue.

Because different IP networks have different addressing requirements, a remote access server must provide flexible TCP/IP addressing options, including by-user, by-port, and client-supplied IP addresses.

By-user addressing helps optimize a system for user tracking. With by-user assignment, the server assigns the client's IP address each time a user dials in, taking that address from the user database. By-user assignment ensures that each user has the same IP address every time he/she makes a remote access connection. This assignment provides an efficient method of ensuring that users have valid IP addresses and provides tracking via IP address what services the user has accessed.

By-port address assignment conserves IP addresses. When a user dials into a specific port, the user is simply assigned the IP address of the port. Therefore, on an 8-port server that might be servicing 50 users, only eight IP addresses are expended.

Client-supplied addressing requires that the server allow the remote PC to choose its own address. Client-supplied addressing provides similar benefits to by-user addressing, but without centralized control. It also supports TCP/IP protocol stack implementations that require pre-configured IP addresses.

The remote access server software also plays a key role in determining the speed of the overall remote access system. As mentioned before, the speed of a remote access system is influenced by the percentage of its available bandwidth that is filled with useful data. The remote access server software can use its knowledge to minimize the overhead per data packet, and also to exclude unnecessary packets from the link.

The remote access server software must understand both the workings of a protocol and the way it is likely to be used in order to optimize link utilization. For example, the server should support header compression, in which the server uses its knowledge that there is only a single remote PC per connection to remove addressing information and other packet overhead. Header compression is different for each protocol.

The server must also ensure that a remote access connection's bandwidth is not wasted on unnecessary broadcast traffic. Broadcast traffic on the server's network is a potential performance killer for any remote access system, particularly on large networks. Broadcast packets are received by every system on a LAN, but each broadcast packet is usually relevant to only a few of the systems on a LAN. If all broadcast packets are forwarded over the remote access connection, that connection fills up with packets that the remote system simply ignores. Meanwhile, valuable data backs up behind irrelevant broadcasts, hurting performance.

The most effective way in which a server can limit broadcast traffic is by acting as a router, which eliminates all broadcasts that are not specifically directed to the remote link. With help from the remote access client software, the remote access server may further determine which broadcast packets are truly needed by the remote system. This is particularly important in bridged environments and for non-routable protocols, where there may potentially be a great deal of broadcast traffic on the server's network.

A good example of broadcast traffic management by a remote access server is found in the NetBEUI protocol, which is not routable, and is particularly susceptible to performance problems caused by broadcast traffic. With NetBEUI, the server can learn all names by which the client machine is registered, respond to name lookups directly, and forward only broadcast packets that are destined for the remote machine's name.

Since all of the optimizations require that the remote access server and client software perform specific performance-enhancing tasks for each protocol, it is necessary for the software to be tuned to the inner workings of each protocol that it supports. A remote access system that is "protocol blind" and treats all protocols the same is unlikely to achieve optimum link utilization.

IP Addressing

Shiva's LanRover family provides extremely flexible IP address management capabilities, including support for by-user, by-port, and client-assigned IP addresses.

Network Management

Network management for a remote access system should be optimized to minimize the total time that a network administrator must invest in setting up and maintaining that system. For small remote access installations, an optimum system usually emphasizes speed, simplicity, and interactive use. For large installations, power, automation, and integration with other management systems are key.

Large remote access systems can be very complex, requiring significant ongoing attention and maintenance to keep them running. Such systems need to be managed systematically, optimally with the aid of a set of network management tools that provide a structure for doing so. For large installations, an up-front investment of setup and installation time pays by providing consistency and predictability in ongoing operation and maintenance.

The tools for managing large remote access installations should include a graphical, Simple Network Management Protocol (SNMP) based monitoring application; a command shell for interactive, real-time configuration changes; and automated code and configuration downloading for basic setup and configuration of the remote access servers. These tools most often reside on a central UNIX workstation.

Large-scale graphical enterprise management systems, such as SunNet Manager, HP OpenView, or IBM's NetView/6000, rely on SNMP to monitor network devices. These SNMP-based management systems monitor the servers in a large remote access installation, as well as the remainder of the network. By providing a single application for monitoring the entire network, such systems simplify a network manager's ongoing maintenance. In order to work with graphical enterprise management systems, a remote access server must fully support SNMP (including MIB II), extensions for remote access, and traps to warn of problems and changes of status.

A simple text-based command shell, used with a graphical monitoring application, provides the enterprise network administrator with a simple, direct path to make interactive, real-time changes to a remote access server's configuration. The command shell is accessed in-band with a protocol such as Telnet, or out-of-band directly through one of the server's serial ports. The network administrator can make simple configuration changes directly from his/her monitoring workstation by Telnetting to a local server or by calling a remote server with a modem.

The final piece of an integrated tool set for managing large remote access installations is centralized, automated downloading of both server code and configurations. Using BOOTP/TFTP, a server can automatically download both its code image and its complete configuration from a central management workstation or server. This allows network administrators to centralize and automate the maintenance of their server configurations. By building a database of configurations and automating the configuration process itself, a network administrators can ensure consistent, reliable behavior in the remote access system.

Small remote access systems are typically simple, with correspondingly simple network management requirements. On-going maintenance of such simple systems should place few demands on the network administrators. Therefore, an optimum management system for small installations minimizes the total time invested in setup and maintenance by providing simple, interactive, easy-to-use tools that demand a minimum of up-front preparation and knowledge.

The tool of choice for managing a simple remote access installation is a Windows- or Macintosh-based application that is specifically designed to work with the system's remote access servers. As a Windows or Macintosh application, it provides a familiar user interface that requires minimal training or special knowledge to operate. By focusing on a particular type of remote access server, the application can present a network administrator with explicit choices instead of forcing him/her to learn all of the management options before attempting to manage the server.

An interactive management application for simple remote access systems should make it possible to manage all remote access servers in an internetwork from a single workstation, should provide access to all the important management options that the servers support, and should be able to perform management operations on multiple servers with a single command. Management software that meets these criteria can provide a simple, effective management solution for network administrators who have not invested heavily in an enterprise-wide network management architecture and/or desire a cost-effective, easy-to-use, and fully compatible network management application.

Enterprise Management

Shiva's LanRover family includes full SNMP support for use with enterprise management tools; a command shell accessible in-band via Telnet or out-of-band through a serial port; and BOOTP/TFTP for centralized automatic download capabilities. LanRovers also support the UNIX syslog for centralized recording of management messages.

Remote System Management

Shiva's remote access servers come bundled with Shiva Net Manager (SNM), a Macintosh- or Windows-based application that can fully manage Shiva remote access products.

LAN Efficiency

As is true with any networking solution, optimizing a remote access system requires the network administrator to monitor and gauge the efficiency of the LAN. If the LAN is heavily used, then remote access performance will be affected. In general, internetworks that are routed perform more efficiently than those that are bridged.

If a LAN segment is heavily used, further segmenting the network via routing technology can provide a higher level of performance both locally and remotely. There are many network monitoring tools that provide ongoing information on LAN bandwidth use. (Refer to your product release notes for additional performance information.)


A complete remote access solution requires the optimization of all its varied components. The demands on a remote access system are many: it must support its users' networked applications, must provide adequate performance, must be easy to use, easy to manage, and secure. A weak link anywhere jeopardizes the integrity of the entire system.

The remote access system designer must carefully consider issues that go beyond the choice of remote access server and client alone. Remote computer hardware must be suited for remote access. Network applications must perform well on low bandwidth links. Different network operating system versions may have significant effects on the system's ultimate success. Security, management, network addressing, and a host of other system attributes must all be tailored for each system's particular needs.

An in-depth understanding of the constituent components of a remote access system, and, just as importantly, an appreciation for system-wide interdependencies, are essential to a successful remote access deployment. Customers should keep end-to-end optimization at the center of their remote access decisions.

See Also