Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

Building Scalable Remote Access

by Mike Fratto  Capacity Planning

Capacity planning for remote access involves a number of different issues and disciplines (queuing theory and statistical analysis, for example) that will provide a general picture of your expected capacity. There are no hard and fast rules for capacity planning for remote access. Call-usage patterns depend heavily upon when and how long users will by occupying lines. Without a large body of traffic data for reference, modeling expected usage patterns and interpreting the results from modeling calculations are extremely complex.

If you decide to do it in-house or outsource the capacity planning, you'll need to understand the various aspects to be considered. Capacity planning is a tug of war between three key factors: the number of ports, the number of calls to be handled, and t he amount of time spent on line per user. A change in one aspect will have effects of the other two.

  • The number of ports connected to the PSTN via a remote-access server is the limiting factor in determining how many users you can support at any one time. Port densities should be determined only after you determine the usage levels you'll have to support. This is also the most costly element you'll need to consider in capacity planning. If you are too low in your estimates, your users will get lots of busy signals, which will cost the organization money in lost revenue and will create ill will. If you over-plan, you'll be paying far too much in costs for equipment and lines.

  • The number of calls submitted is difficult to quantify because of the many different types of users. Some will use remote access more frequently during certain times of the day while others will only use it on special occasions, such as on trips. What is important is the number of calls that need to be serviced during a given time period. For example, midmorning to midafternoon may be peak hours with users contending for busy ports while early morning or late evening you have ports sitting idle.

  • Time Online is difficult also because each user will have to do different things while connected and there are far too many variables associated with remote access to nail down solid figures. You can get a fairly good idea of how long common tasks will take to perform by using a protocol analyzer and running tests over a remote-access link. A key to lessening the time spent online by users is to get them into the habit of getting on and off quickly.

Simple user-to-port ratios don't work well when estimating needed port density because not all users will be contending for ports at the same time, users will be online for different time periods, and the actual number of users will most likely be less than your registered users. There are a few tr affic calculation demonstration applets available on the Web (notably Sage Telecommunications and Westbay Engineers Ltd ) that give an idea of how the three criteria above interrelate.

You can use a type of calculation know as ErlangB calculations to indicate the probability of a blicked call. By themselves, though, they do not calculate bandwidth requirements. The Erlang-B equations assume that the probability of an attempted call will be uniformly distributed and that the calling pattern is sufficiently random over a period of time (generally one hour). Capacity planning typically involves finding an acceptable balance between quality of service and resources. The Erlang-B models can estimate probability of getting a busy signal given a worst-case scenario for a set of parameters that describe the remote-access system. From there, you can work backward to gauge the theoretical number of lines based upon an acceptable population and quality of service.

However, the ErlangB models are not as straightorward as they seem. Your user population won't necessarily behave predictably (within the norm). Getting the data to make an informed decision is a Catch-22 because will you have to gather and evaluate a large body of information on your user base, but much of that data (usage trends and calling patterns) won't be available until your remote-access system is in place. Unless you have a lot of experience in your organization with capacity planning, you'll be better off finding a consultant or contacting your carrier for assistance in capacity planning.You will also have to work with your carrier to get data such as the number of calls attempted to a given trunk or line versus the number of successful calls completed.

Updated January 17, 1997




Print This Page


e-mail E-mail this URL

Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers