Connection Failure IET : Remote Access
Connection Failure

Remote Access

RAMP Report, 10/12/98


Table of Contents   |    Acknowledgements    |    Section:  1   |    2   |    3   |    4   |    5   |    Appendices




Usage Analysis


Analysis of Existing Modem Pool

Access

Analysis of Internet Traffic through the Modem Pool

Summary of Legacy Modem Pool Usage

Performance

Analysis of Existing Modem Pool


The existing campus modem pool, excluding the September, 1998, expansion, consists of 459 Telebit T3000 V.32 modems connected to Cisco ASM terminal servers. The campus modem bank is divided into two groups: 396 authenticated PPP/SLIP modems and 63 general use telnet ports. Multiple T-1 lines through two supertrunk groups provide remote connectivity to CISCO ASM communications servers through the modems.

Clients of the modem pool are approximately 80% students, 7% faculty, and 13% staff and others. The modem pool serves approximately 4,300 unique clients daily with an average usage of 25-30 minutes per connection. This pool has proved inadequate to support increasing demand for remote access. This usage increase is driven by increases in the following:

  • Telecommuting
  • Collaboration with faculty and researchers at other institutions
  • Distance learning and teaching
  • Reliance on electronic information resources
Access

Load balancing and monitoring of the active session patterns indicates that maximum usage occurs between 5 p.m. and 1 a.m. during a "typical" day, for both general use and SLIP/PPP. This is shown in the figure, "Modern Usage vs. Time of Day". The shape of this usage pattern remains relatively constant throughout the academic year with only slight variation in the usage amplitude. The dark line in the chart represents a "trend" point for the period 6-12 January 1998, a typical week of data for SLIP/PPP usage.



Back to top   |   back to Table of Contents.



Call Rejection

During the hours of peak usage, customers receive a busy signal when all the trunks are filled. The Modem Usage vs. Time of Day chart also indicates the time of day that a customer is most likely to receive a busy signal. Call rejection may also be a function of modems refusing a call due to improper string commands, authentication, or frozen modems. Of the three, the frozen modem is the greatest cause for concern because this condition cannot be cleared until after the connection is dropped. Frozen modems require a manual reset of the modem port. On a particularly high usage day during Finals Week, approximately 22,000 calls were offered to the general use modem bank. As many as 35% (7,836 of 21,898) of the calls attempted were rejected because the modems refused the call. Busy signals during the same high-use period approached 7,800, representing approximately 26% of the incoming calls. Prior to the load balancing for SLIP/PPP connections, rejects of up to 42% (10,540 of 24,890) due to modem/string problems were noted in excess of 10,000 busy signals (approximately 30% of the incoming) also being received.

Contention Ratio

A contention ratio is the ratio of the number of users per remote access port. Industry standards indicate that for satisfactory service in the general Internet community, the ratio of users per port should be between 10 and 12 to one. The contention ratio of the existing modem pool prior to the RAMP pilot was approximately 4 times this at 41:1. Based upon the following characteristics of use, pilot participants did not report connection problems until a contention ratio of approximately 20:1 was achieved. This is the current contention ratio after adding 480 modems to the pool through the Provost's Office funding allocation and the conversion of the RAMP pilot to full service.

The connect times of pilot participants varied from dedicated connections with high idle time to connections of 1-2 minutes for e-mail transfer. The average pilot user connected approximately three times daily with a session length of approximately 35 minutes. During the RAMP pilot, users did not experience busy signals or disconnects due to the extremely low contention ratio. To test the system, multiple incoming lines were disconnected during peak periods, and ports were intentionally occupied, in order to artificially drive the contention ratio higher until congestion and contention occurred.


Analysis of Internet Traffic through the Modem Pool


Internet Traffic Analysis across Border Router

Between March 25, 1998 and April 12, 1998, data was gathered on the source and destination of traffic seen transiting the campus border router which monitors source and destination traffic.

An analysis of the traffic during this period shows that 9% of the traffic travelling to a destination through the campus network is destined for clients that are connected through the campus modem pool. Of that 9% of the total traffic, 22% was generated from the campus and 78% from the Internet, with less than 2% total from ResNet, Davis Community Network (DCN) and the UC Davis Health System (UC Davis Medical Center). This breakdown is shown in figure 3.2.





An analysis of the traffic during this period shows that 2% is from clients that are connected via through the campus modem pool. Of that 2% of the total source traffic, 63% was directed to the Internet and 37% to the campus, with less than 1% total directed to ResNet, DCN and UCDHS Modem Outbound. Figures 3.3 and 3.4 show these measurements.





Based on the percentage of traffic transiting through the border router, a review of the Internet source and destination traffic indicates that the modem client impact is very mild. The percentage of all Internet traffic across the border that originates from the modem pool represents less than 1%. The percentage of all traffic originating from the Internet and destined for the modem pool is 7.9%. As the university pays for all Internet traffic transiting through the border router, UC Davis is paying on an approximate 8:1 ratio for Internet requests and replies; although the actual throughput is low.

However, expansion, augmentation or replacement of the current modem pool must be considered in light of possible increases in traffic flow and customer base size. Increases in these areas will impact overall Internet usage and fees paid. The Internet link has frequently peaked at the 10Mbps maximum. The university pays approximately $325,000 per year for its Internet connection. If the user base expands to include all potential clients, it is expected that campus modem-based Internet traffic will increase as well, causing further demand on the 10Mbps link and contributing a greater share in the cost model for Internet access. A move from dial-in modem services to ISPs for the current client base of approximately 18,000 users may represent approximately a 16% reduction in campus-funded Internet traffic.

Summary of Legacy Modem Pool Usage

The 14.4Kbps system is a resource that has reached the end of its serviceable life. Without proper vendor support, compliance with Y2K code, and spare parts, the service can only continue to deteriorate.


Performance


Many applications require higher access speeds than 14.4kbps. Web browsing, file transfer and several diagnostic tools, although capable of being run at the lower speeds, are inefficient when run at the lower speeds. Specific applications that require large amounts of data transfer or graphics to be transferred (DaFIS or Class Courses) will often time out or hang a user's system when attempting to run at 14.4Kbps.

High bandwidth applications, large data volumes, graphics and detailed network searches are key factors to consider when implementing a remote access solution. Modem technology, although advancing connection speeds at a fast rate, may not be able to adequately provide for the needs of high bandwidth remote access users even at the current 56K V.90 standard in the near future. Modem vendors are already exploring connectivity at 128Kbps and greater from the desktop modem, with one vendor predicting that this technology will be available within the next 12 months.

Back to top




Table of Contents   |    Acknowledgements    |    Section:  1   |    2   |    3   |    4   |    5   |    Appendices


Connection Failure