Network Planning with a Performance Prediction Tool
A new type of tool facilitates network engineering by combining the speed and practicality of mathematical analysis with a graphic user interface that is customized for network modeling.
By Stephen D. Post, Ph.D.
When you design a new network, upgrade an existing network, or accommodate new technology or user requirements, it would be valuable to test whether the design will handle the workload with acceptable performance – before you commit to the risk and expense of actual implementation. Ideally, the planned design will be supported by a business case that quantifies the costs and impacts on user productivity and business objectives, and will consider various alternatives. This article overviews how network planning is done now and describes a new tool designed to support better planning.
The four general approaches to network planning are described below. Although no empirical evidence is available, experience suggests that the approaches are listed in order from the most common to the least common usage. In fact, the fourth approach is probably used in less than 2% of cases.
Buy and Try: The basic concept is to wait until a performance problem arises, figure out which components might be bottlenecks, and upgrade them. This approach has an admirable simplicity and often finds good solutions, but is poor at avoiding problems and can be wastefully expensive due to its short-term, piecemeal approach. The business case is typically, "we have to spend this money to solve the problem".
Rule of Thumb: This approach relies on back-of-envelope calculations and parallels to previous experience. For example, "a 10 Base-T LAN with 30 office users will have about 20% utilization, and it can usually handle up to 60 users without a problem", or "a T1 line is enough for remote sites with under 10 people". This approach is very efficient in terms of planning effort, and is often quite effective, especially when the experience is expert and the components are not heavily loaded. However, it falls short when cases diverge from past experience, or when you want to fine-tune the cost and performance. The business case typically boils down to "trust me, this is what we need".
Spreadsheet and Mathematical Analysis: Practitioners collect data and design spreadsheets that estimate loading by component. They may also enter queuing or other formulas into math packages to estimate delay. This approach typically gives good results, but it requires considerable expertise, the setup can be time consuming, and the accuracy tends to be rough – especially for delay. The business case will be documented and quantified.
Simulation: Practitioners collect data on the projected network topology, protocols, and workload and enter the data into a commercial tool through a graphic user interface (GUI) that is customized for network modeling. (To baseline an existing network, most simulation tools can import network topology and traffic from network management tools). Clever model definition is required since simulations typically do not scale up to model all the users in an enterprise. Then, a discrete-event simulation is run long enough to attain a steady state, with repeated runs to ensure that the error of the mean is small enough. The simulation approach can potentially give the most accurate results, but it requires senior expertise, and can take weeks to set up and days to run. The long run times limit the number of alternatives that can be explored. The business case will be documented and quantified.
The buy-and-try and rule-of-thumb approaches qualify more as craft than as engineering. Their use suggests that the discipline of network engineering is still catching up with the dramatic push of technology and pull of demand. Of the two engineering approaches, mathematical analysis is used much more commonly than simulation, due to its relative practicality, but is much less supported by custom programming applications.
A Tool that Supports Mathematical Analysis
NetRule is a new tool from Analytical Engines Inc. (www.analyticalengines.com) that is designed to combine the best features of mathematical analysis and simulation tools. It has a custom GUI like the simulation tools, with built-in expertise about network components and modeling, and can also import baseline data from network management tools. Yet, it uses closed-form mathematical analysis that evaluates network load and performance in seconds - with detail and accuracy that matches the best practice of mathematical analysis. The result is a practical engineering tool that can support the exploration and quantification of a number of network design alternatives.
Using the Tool
NetRule lets you create or open network models and libraries, edit them graphically, and evaluate their performance.
Figure 1. The user interface is laid out like a browser
The interface, shown in figure 1, is similar to that of a browser in that all the displays are linked via hypertext, and you can page forward and backward. The panel on the left gives you hierarchical access to all the network objects, organized by subnet or object type. The access includes browse, edit, and drag-and-drop. The panel on the right displays data as a diagram (shown), object-attribute form, list, histogram, report, or documentation. The diagram can animate message flow, highlight bottlenecks, and show utilization and delay bars by component.
Network Objects
A network model consists of a set of network objects and their relationships, as shown on the entity-relationship diagram (see figure 2):
Figure 2. NetRule uses a small set of modeling objects
The physical network components are represented by Computers and Links. You create the network topology by connecting these objects and by grouping them into Subnets. The network workload (message traffic and server activity) is represented by Jobs.
NetRule uses shared object definitions to reduce modeling time and allow you to make global changes. The shared objects that define computers are Computer Profile and User Profile. Links are defined by Link Protocols. Jobs are defined by Job Profiles and Destination Lists. Job Profiles are defined by Transport Protocols.
Object Browsing and Editing
You browse and edit network objects on a page like that shown in figure 3.
Figure 3. A page to browse and edit a network object
This particular page shows the Link attributes. The link is defined primarily through its link protocol, so there are only a few editable attributes (in white). The little buttons let you pick a new protocol or browse to the selected protocol. The display includes statistics that NetRule has evaluated for the link (in gray), and queries that will list related objects (in blue).
Shared Definitions
Figure 4 is an example of an object that is used as a shared definition, in this case as a Transport Protocol.
Figure 4. Shared definitions save modeling time
You are free to create or change protocols and profiles. Any changes that you make will affect each object that refers to the definition.
The NetRule library includes: Reports After you evaluate the model with the click of a mouse, you can examine the results. Figure 5 is an example of a report, in this case for link statistics. Figure 5. An example report Reports are available for object definitions as well as for evaluation statistics. You can browse from any row to the source object, you can sort any column, and you can export any report to spreadsheet, database, presentation, or graphics packages. Periods Period objects let you establish different workloads during different times of the day (e.g., "Day" and "Night" periods) or times of the year (e.g., "Qtr1" and "Qtr2" periods). You can use a period to establish different configurations (e.g., "with Frame Relay" and "with ATM" periods) or breakdown situations (e.g., "all components ok" and "one link down" periods). To do this, each period has its own loading factors, and enables only the jobs or components that apply to that period. You can also have multiple versions of the same job or component, but parameterized for the different periods. Figure 6. Periods let you compare different times or conditions A report by period (see figure 6) has a column for each Period, and displays one of the following attributes for each object: Histograms The distribution of delay is an important factor in your network analysis because the performance requirements might be stated in terms of a percentile, and users are sensitive to large variations in delay, even when the average delay is acceptable. Figure 7 is an example of a histogram showing the delay for sending e-mail from a client to the server. Figure 7. Histograms show the distribution of delay The probability density function is shown in red, and the cumulative probability density function is shown in yellow. The delays can be for: transmission time on a link; CPU or disk processing time on a server; and job transmission, processing, reply, or total time for a job. When you click or drag the mouse on the histogram, the corresponding cumulative probability is displayed. You can use this feature to identify the median, mode, and delay at any percentile. Import Topology and Traffic NetRule imports your network topology that has been discovered with a network management tool. Just export the topology to a database and dump a list of computers, links, and connections for NetRule to read. NetRule also imports traffic from your network that has been captured with a network management tool. Just fill in a dialog like that shown in figure 8. Figure 8. The dialog to import network traffic Conclusion With the availability of tools such as NetRule, there is less need to craft networks through buy-and-try or rule-of-thumb approaches. It has become more practical to engineer networks based on rigorous analysis of contending alternatives, and build a strong business case that is quantified as to performance and costs. Stephen D. Post, Ph.D. is the President of Analytical Engines Inc, which produces NetRule. He is also the chief developer of NetRule. He previously headed the Simulation and Artificial Intelligence (AI) departments at PRC and CACI, where he carried out a number of network simulation projects, and he has written and taught extensively on AI and simulation.>
