PSTN's Particularly Pesky Problem

By Robert Moskowitz  We can no longer function without remote access. To keep pace with the rest of the world, it must be a part of our network offerings. Yet the cost of providing remote access can be very high compared to the value it adds to a company. As with any technology, the cost of ownership consists of the one-time, up-front fee, recurring costs and unscheduled costs. With remote access, up-front fees are the smallest cost, and recurring costs and unscheduled costs must be brought under control. The problem goes beyond getting the best remote-access server. The server represents much of your one-time cost. Most of the unscheduled and hidden costs associated with r emote access can be attributed to the PSTN (public switched telephone network) services used by the remote units. The Problem With PSTN Imperfections in the PSTN fabric can be found in the call switches and user facilities, like PBXes. Or, to be more exact, the problem is in the number of switches and PBXes involved in a call. The load on these has a direct impact on connection clarity and the quality of the modem signal. Review your modem statistics. A disconnect reason of "V.42 error overrun" (or similar wording) should send off alarms. This message refers to a hard-modem disconnect because of corrupted V.42 frames. V.42, the error-correction protocol used in almost every modem, is a synchronous framing protocol that provides a very sophisticated parity check on the data sent between modems. Synchronous means that all the parity bits are after the frame's data, instead of after each byte. This method reduces transmission overhead, resulting in fewer parity bits for the frame as opposed to the number of parity bits in the asynchronous data stream sent by the computer to the modem. The purpose of the V.42 protocol is to catch transmission errors and correct them. If a modem receives a corrupted V.42 frame, it sends an REJ (reject sent frame) back to the sending modem. The sending modem retransmits the frame. The receiving modem will continue to REJ until it gets a good frame or until it REJs the frame 12 times; at that point, the receiving modem drops the line because of V.42 error overrun. What's causing these V.42 error overruns? The corrupting force the PSTN has on the modem signal: It alters the data and distorts the V.42 frame. I have seen statistics from a modem bank with as high as 20 percent connection drops because of V.42 error overruns. These occur within the first five to 10 minutes of a session. V.42 error overruns are frustrating for remote users who do not see the real session-drop reason--the PSTN is out to get them--but, rather, perceive the problem as a login failure. When you match these modem statistics with caller ID data, you often see regional or time-of-day problems. The real bugaboo here is the number of switches involved in the call--something you cannot control. I once set up a remote-access system and tried to bypass most of the PSTN by using an 800 service; the connections to major 800 systems are supposed to be tied into each central office. My system users experienced significant V.42 connection failures with the 800 service, and analysis showed that in those locations with regular V.42 connection failures, five or more switches might be involved in the call delivery. The same users found that they did not have this problem calling a local ISP where only a few switches were involved in the call. Let 1,000 Remote-Access Servers Light the Way Few companies can afford to deploy remote access in a way that will address the shortcomings of the PSTN. To do so would require an extensive understanding of the PSTN infrastructure and a remote server in every majo r remote-user location. You'd need a few hundred remote users in a location to justify a local remote-access installation, fewer if you have a branch office for the equipment's location and corporate connection. Given this economic reality, only large, geographically diverse companies can avoid the noise on the PSTN. For the rest of us, pooling our users in order to get the hundreds of thousands of remote users needed to justify such a setup is our best option. Of course, there's a significant deployment of remote-access servers in almost every city in North America (and much of Europe). Large ISPs have deployed a high enough density of access servers to handle most companies' remote-access needs. The smaller ISPs can provide coverage in small communities. The challenge is leveraging this coverage to address our remote-access needs. The goal is to control access costs, provide privacy and maintain performance. Blending Business and Bytes The lowest-price ISP for your remote users does not necess arily have the lowest access cost. V.42 error overruns will cost you in employee time and productivity. An ISP should provide a prospective corporate customer with its session statistics, showing current session-length distributions and speeds, particularly sessions with speed drops. This information is available to the ISPs in their modems' MIBs. We must rely on the ISP to provide us with these reports. ISP-monitoring companies that are collecting similar data from a central site of simulated users cannot properly measure the PSTN impact on local callers. Their long-distance calls go through extra switches to get to the ISP's modem banks. The busy statistics, however, are valid and worth reviewing before selecting an ISP. Look at reports that will reflect on your users' calling patterns. One new development may change this situation for your users and the ISPs. Phone-switch companies are addressing the impact modems have on the PSTN by building switches that recognize modem calls and immediately sw itch them off the PSTN. Different methodologies are being marketed for how calls are sent to the ISP, but the more important impact of this new technology on remote users will be clearer calls. These clearer calls should not have the V.42 error problems and speed degradation of the PSTN. A necessary ingredient of affordable remote access is a clean connection between the remote user and the access server. This means avoiding as much of the PSTN as possible. Right now, your best course of action is to team up with an ISP (or group of ISPs) that can give you extensive local coverage. Take care in selecting an ISP; it is important to maintain your ability to change providers. Do not go in for extra services that will lock you into a particular provider, like an ISP-provided security service. In the ever-changing business of ISP provisioning, you should look at your ISP like just another corporate supplier. Robert Moskowitz is a senior technical director at the International Computer Security Associatio n and a member of the Internet Architecture Board. He can be reached at rgm@htt-consult.com.

Other Columnists Net Results By Dave Molta On The Edge By Art Wittmann