ACM / Crossroads / Xrds10-1 / Network Resource Planning

Network Resource Planning

by Beatriz Acosta and Kostas Pentikousis

Introduction

According to Robert Metcalfe, inventor of Ethernet, "the value of a network is proportional to the square of the number of users (or hosts) that it connects." This statement, dubbed Metcalfe's Law [11, 14], attempts to explain the tendency of networks to expand. According to this assertion, a positive feedback loop governs the network so that as it encompasses more resources, it attracts new users, which in turn want to connect more computers. Metcalfe's Law was crafted based on experience with the Internet, yet it applies to any kind of network ranging from private enterprise data networks (VPNs) to public telephone networks (PSTN) to interlibrary loan services.

Building larger networks implies higher infrastructure and maintenance costs, and increased sophistication. Any additions or modifications to a large operational network necessitate a plan, which should be devised after understanding existing weaknesses and vulnerabilities, and identifying current and future needs. This article will introduce the fundamental concepts of network resource planning (NRP), a methodology used to design, upgrade, and expand computer communication networks, and will focus on how such a methodology can be applied in enterprise networks.

Network Design Constraints

A network designer can use many archetypes to determine a network's architecture. Yet, not all networks are created equal: Differences in topology (host, router, and link location and dependencies), software and hardware configuration, and protocol deployment make every network unique. As a first step in NRP, the network designer must consider both the functional and non-functional requirements [7]. Functional requirements specify what the software (or hardware) is expected to do. For example, a Web browser is expected to communicate with Web servers, fetch Web pages, render the received content, and display it to the user. Non-functional requirements, on the other hand, specify global constraints that must be met by the software. For example, users are not willing to wait for long periods of time for a Web page to be displayed. Although delays can be introduced by slow network connections, browsers are expected to render pages expeditiously. Inefficiencies in a browser's page rendering engine can break this non-functional requirement. In general, non-functional constraints, also known as global software attributes, include performance, fault tolerance, availability, and security. Such criteria define what is known as the quality of service. One of the goals of NRP is to improve the quality of service enjoyed by the applications relying on network resources.

In principle, there may be several architectural solutions involving different network, software, and hardware configurations. However, as we shall see later, usually only a small subset satisfy the non-functional requirements. NRP allows network designers to optimize resource usage, guarantee a given level of service to distributed applications, and minimize operating costs [1].

The final output of an NRP study is a new and improved logical and physical design of the network. During this study, many issues have to be dealt with, including requirements compilation, choosing appropriate technologies, and capacity planning. The following sections describe the network design process, from the compilation of the requirements to the final design of the network.

NRP in a Nutshell

NRP can be broken down to three main steps (Figure 1) [1]:

Figure 1: The Network Resource Planning process.

1. Baselining identifies the overall enterprise goals, specifies the technical objectives, and records the current network infrastructure and state of operation. Baselining provides the designer with a basic understanding of the enterprise needs, and an account of available resources. In addition, it can indicate performance issues and isolate problems, such as bottlenecks and single points of failure. In other words, baselining studies past network experience, and scrutinizes current needs and requirements in order to forecast future network performance [8].
2. Application Planning produces a characterization of future applications that will be deployed in the current infrastructure. The term characterization refers to the process of analyzing the traffic patterns of future applications before they are deployed in the actual network. Application traffic samples are collected and are analyzed in terms of transfer sizes, peak resource demands, average transaction durations, and other behavioral characteristics.
3. Capacity Planning uses simulation and modeling to obtain measurements under different scenarios, in order to test alternative network design proposals. Based on the simulation results, the network designer will decide which architectural solutions are better. Parameters that are evaluated include the topology (for example, the geographical and logical location of servers and other network components), the protocols, link capacities, and network interface buffer sizes.

NRP can be used to:

• Plan network expansions
• Perform a cost/benefit analysis of proposed network upgrades
• Assess the impact of a new application on the existing infrastructure. This sometimes leads to a redesign of the network in order to satisfy new and existing requirements
• Detect the causes of network problems (e.g., congestion delays)
• Estimate the capacity/utility of a proposed network
• Evaluate significant changes to the network such as topology modifications, new protocol deployment, addition of servers, and client relocation
• Improve network performance, security, and reliability for mission critical applications
• Reduce network operation costs
• Move to a global-network business model
• Offer new network services

NRP studies should be repeated periodically to obtain maximum performance and indicate possible problems. Although network topologies do not change very frequently, usage patterns do. Users like to endorse and deploy new, "hot" applications (remember Napster?) that can cause significant changes in network utilization, drifting the network operation point far from its "optimal" position, and leading to poor performance.

Baselining

During the baselining phase, network designers map the existing network, creating several different diagrams, in an attempt to comprehend the current topological dependencies, and refine the requirements for the network. This mapping exercise is performed at several levels of abstraction: One diagram can include only the backbone network, and possibly the main enterprise servers, while others present detailed views of subnetworks connected to the backbone. For example, Figure 2 presents a partial view of a larger network diagram, which highlights six copper and two optical ("F.O.") links connecting one IP border router and seven Fast Ethernet switches. Notice that the diagram does not include any end hosts (servers or workstations), and indicates via the dashed rectangle that four of the Fast Ethernet switches belong to the same logical entity.

Figure 2: A network diagram.

If the network spans across continents, countries, cities, and campuses, the network maps should include this geographical information, underlining the respective interconnections. Moreover, it is important to map the logical infrastructure as well, which involves documenting any policies for network addressing and naming [20]. A second level of detail includes Wide Area Network (WAN) and Local Area Network (LAN) connections between buildings and campuses, specifying the Data Link layer technologies employed (e.g., ATM, Frame Relay, Fast Ethernet, and xDSL). The location of principal network components, servers, Virtual LANs (VLANs), firewalls, and other relevant elements must be clearly indicated. In addition to the set of network maps, an inventory of available network resources must be created. Information such as server and router models and network capacities should be collected in order to evaluate the capabilities of the existing infrastructure.

Nonetheless, baselining is much more than network cartography. Understanding the enterprise business goals, which includes determining any business constraints, is crucial and will affect the subsequent design phases [15]. Key questions that must be answered include:

• What will be the main use of the new network?
• Are there any other important, but not vital, current and future uses?
• What is the network's role in achieving improved financial results, such as, reduction in operational costs, revenue increase, or market share expansion?

In addition, it must be investigated whether the network can enable partnerships with other organizations, streamline operations, and improve the quality of business decisions. For example, linking one's inventory database directly with suppliers can dramatically cut costs and improve customer satisfaction. There is a strong connection between business goals and technical objectives, since the former guide the network designer to define targets for capacity, performance, security, availability, and reliability.

After determining the business priorities, one is expected to determine the technical objectives or, in other words, to define the target level of quality of service. This level is usually defined in terms of a number of parameters, including [15]

• Scalability: how much growth or expansion a network design can bear. For example, the designer must take under consideration the restrictions that some networking technologies impose on future capacity increases.
• Availability: the amount of time the network is operational. Usually this parameter is specified with great precision, and for a good reason: although an uptime of 99.95% means that a network is down 5 minutes per week, an uptime of 99.70% represents that the network is down for 30 minutes per week. The latter may be unacceptable.
• Network Performance criteria such as throughput (bits per second), packet drop probability, average and maximum packet delays, transaction response time, etc.
• Security is one of the most important parameters that steer the network design process. The designer typically commences a risk analysis, defining security policies and determining the security mechanisms to be deployed.
• Recoverability: how easily and how quickly a network can recover from a severe problem.
• Resiliency: how much stress a network can handle, and how fast it can rebound from problems.
• Adaptability: a measure of how agile a network is to changes or the introduction of new technologies. For example, a flexible network design can adapt to changing traffic patterns.
• Manageability: According to the International Standards Organization (ISO), the manageability functions of a network include: (a) performance management, which includes analyzing traffic to optimize resource utilization; (b) accounting management to allocate costs or to plan changes in capacity requirements; (c) fault management (to detect problems); (d) security management (monitoring and testing the security of network services); and (e) configuration management (controlling, operating and collecting data from managed devices).
• Usability: a measure of how easily can users access network services.
• Affordability/cost-effectiveness, which translates into being able to carry the maximum amount of traffic for a given cost. Certain levels of quality of service are not inexpensive, and price-sensitive enterprises should consider alternatives. A cost-effective network design should address such issues.

After determining the business and technical goals the network designer must meet, she has to prioritize them and define the NRP objectives. As an example, an objective could be to characterize a new application before it is deployed in the network and estimate the resource demands it would place on the actual infrastructure, thus verifying whether the required quality of service target can be met. The technical goals provide guidelines for the next phases of the design process, and allow the designer to make informed choices about the technologies that must be used to meet the specified requirements.

The next step during baselining is to collect samples of actual network traffic. Traffic samples are used to analyze problems in the existing network, and to obtain the network activity profile. This process is usually broken down into two sub-processes that are referred to as usage-based data and application-based data. The former sub-process attempts a more general analysis than the latter. In both cases, traffic analysis demands an inclusive look at network behavior.

Usage-based Data

Usage-based data is needed to build a comprehensive view of the network. Data can be gathered using traffic analyzers and usage statistics collected from routers, switches, and firewalls present in the network. In general, after analyzing samples gathered during certain periods, a pattern emerges specific to the enterprise network at hand. The information about traffic characteristics includes views of significant network devices and reports on traffic volumes and rates for major network components [1].

The usage-based data sub-process includes characterizing the usage of specific router network interfaces. The analysis should consider a number of variables such as the average and maximum utilization levels, number of users, application utilization, and the corresponding protocols in operation, error statistics, most utilized interfaces, and the periods when send/receive rates exceed a threshold. Knowing which interfaces are used most, which routers go through extended periods of high processor (CPU) utilization, the periods of peak utilization, the number of packets processed, the status of select interface buffers, and whether the number of dropped packets exceeds certain thresholds on a regular basis may show the need for deploying more capacity. Highly used interfaces may represent potential bottlenecks. On the other hand, underutilized interfaces may represent potential cost savings [13].

Of course, the suggested peak utilization in a network depends on the protocols used. For example, Metcalfe and Boggs provide an analysis for CSMA/CD Ethernet networks running at 10 Mb/s [12]. They compute throughput as a function of the packet length and the average of number of hosts waiting to transmit, Q. Throughput remains close to 100% for relatively large packets (512 bytes) even when Q is as large as 256 bytes. On the other hand, when minimal-length packets are sent, throughput drops substantially to approximately 37% (1/e). Therefore, the designers designate threshold for good performance on a case-by-case basis.

Another important issue is the periods during which data is gathered. The sampling periods must include times where the traffic loads reach a peak. Traditionally, the sampling periods are divided into smaller intervals, sometimes as long as one hour, but smaller intervals are preferred. The statistics collected during these intervals can indicate the busiest periods during a day. It is important to select "typical" periods for the analysis. By and large, baselining does not consider problems caused by exceptionally large traffic loads unless the NRP objectives identified earlier indicate that one of the goals is to improve performance during peak load periods. In other words, choosing the "typical" periods depends on the goals set forth by the network designers.

A common way to study the data collected is by creating graphs that depict the network activity. For example, Figure 3 presents the traffic load on the inbound and outbound network interface of the Universidad de los Andes gateway router. The traffic load was sampled every five minutes during a weekday in late January 2003. The maximum capacity of the link in each direction is 7.2 Mb/s.

Figure 3: Daily traffic (Kb/s) through a router's network interface. Blue corresponds to incoming traffic, green to outgoing traffic.

Given a graph like Figure 3, one can discover network behavior patterns, flag "busy hours," and record the peaks in network utilization. For example, this graph depicts a clear pattern of high utilization between 8 AM and 7 PM, followed by a peak just before 10 PM. It is interesting to note that the overnight traffic load is approximately the same in both directions. During this weekday, the average link utilization is 25.5% (1783.8 Kb/s) for outgoing traffic and 50.1% (3504.0 Kb/s) for incoming traffic with the maximum utilization reaching 48.8% (3417.3 Kb/s) and 87.4% (6115.7 Kb/s), respectively.

Figure 4 presents the traffic going through the same interfaces over the course of five weeks. The traffic load is sampled every 30 minutes. The average utilization is 21.9% (1534.2 Kb/s) for outgoing traffic and 40.9% (2865.1 Kb/s) for incoming traffic. The maximum incoming utilization exceeds 93% (6519.9 Kb/s). The corresponding outgoing peak is significantly lower at 65.6% (4592.0 Kb/s).

Figure 4: Monthly traffic (Kb/s) through a router's network interface. Blue corresponds to incoming traffic, green to outgoing traffic, and purple to maximum incoming traffic in a 30-minute interval.

Figure 4 illustrates the growth in network utilization during the first month of 2003. It is obvious that during the first week of January, when classes were not in session, network utilization was low. However, as students started to come back from the winter break, the peak utilization exceeded 93%. Traditionally, network utilization higher than 80% is considered detrimental, and certain measures may be in order. Furthermore, notice the sudden drop in the traffic load at the end of the fourth week in January. During this weekend, the network administrator placed a quota on the traffic destined to ports above 1024. This decision was taken after determining that peer-to-peer file exchange applications (most notably KaZaA) were consuming nearly 40% of the total bandwidth, forcing other interactive applications to exhibit unsatisfactory performance. As it can be surmised from Figure 4, with the quota in place, the incoming network utilization was decreased to 20%. In general, non-interactive applications with large volume data transfers, such as network backups, should be scheduled during off-peak hours.

Based on the data, the next step is to identify hosts, applications, protocols, and users responsible for peaks in network activity. As we will see shortly, this step is performed during the application-based data analysis phase. The designer should collect all relevant information regarding every active protocol in the network, because, in general, the greater the number of active protocols, the higher the overhead.

Application utilization is another piece of the puzzle, because simply establishing how many and which network protocols are being used in the network is not sufficient. The main applications as well as their users must be identified, although the individual applications and their network efficiency will be studied in detail later. Finally, the designers evaluate the overall error statistics. Although it is "normal" to have errors in a network, the error levels must be kept within acceptable bounds. For example, in the case of an Ethernet LAN, a contention-based algorithm (CSMA/CD 1-persistent) regulates frame transmission, which allows for frame collisions. The literature suggests that when collision rates are regularly above five percent, one should segment the LAN [9].

Application-based Data

Once the usage-based sub-process is completed, network designers take a closer look at the applications that generate the observed traffic loads. Analyzing application-based data permits the designer to characterize in some detail the behavior of applications in terms of traffic volume, source and destination pairs, "largest" users, and so on. This process, called application profiling, creates a representative statistical model (a profile) of application transactions based on the data captured in the previous steps. This profile will be used to represent the "typical" load that an individual application user would place on the network. The profile can be used along with the baseline network model to project traffic loads and examine usage patterns under scenarios were the users perform "typical" transactions. This way, the network designers can evaluate whether the quality of service objectives can be met.

Application profiling extracts information from the data gathered, such as application types (and their corresponding application-level protocols, for example for a TCP/IP network: HTTP, SMTP, FTP, and SSH), transaction starting and ending times, source and destination nodes, average packet sizes, and the total number of bytes transferred in each transaction.

The output of the application-based traffic analysis includes the applications that consume the most network bandwidth, which we will call "top applications," the throughput of network transfers for an individual user or application, the duration, and of course, the nodes that contribute the most to the traffic load induced into the network. McKellar points out that in most networks, a small number of nodes generate 80% of the overall traffic load, thus consuming the most bandwidth [10]. For example, we have analyzed the traffic load in a switched Fast Ethernet LAN at the Universidad de Los Andes, which includes several servers and workstations. Although 18 servers are hosted in this subnet, Figure 5 illustrates that the top three nodes indeed produce more than 80% of the total traffic load. Network designers generally focus on these nodes and closely monitor their traffic patterns and performance. Note that the figure presents the measured traffic loads in terms of percentages, but does not reveal the real IP addresses of the hosts. Instead, we use "sanitized" IP addresses for illustration purposes.

Figure 5: Traffic load generated (percent of total load) per host in a switched Fast Ethernet LAN.

Figure 6 and Figure 7 present the top applications during a weekday in January (Figure 3). Clearly HTTP [5] is the most-used protocol ,representing 62% of all incoming traffic and 48% of all outgoing traffic. KaZaA-related traffic, on the other hand, ranks second and third in terms of share in outgoing and incoming traffic, respectively. As mentioned earlier, the university is currently restricting this type of traffic. Without these restrictions, the peer-to-peer file exchange application tends to monopolize the bandwidth, leading other applications to bandwidth starvation. If the situation gets out of hand, the end-effect is similar to distributed denial of service (DDoS) attacks. The graphs also show that a significant share of the total bandwidth is consumed by "unknown" applications, that is, by application-level protocols that do not use standard, well-known port numbers.

Figure 6: Top applications (incoming traffic).

Figure 7: Top applications (outgoing traffic).

Application Planning

When NRP is applied in operational networks, it is important to ensure that new applications will not degrade the performance of existing ones and that the non-functional requirements of all (new and existing) applications are satisfied. This requirement poses more challenges to network designers than does designing a brand new network. For this reason, it is necessary to estimate the behavior of each individual application deployed in the existing network in order to determine the impact on the current infrastructure.

Similar to baselining, application planning is, to a large extent, a data collection exercise, which focuses on applications that will be deployed in the network. Information such as the number and location of users and servers, the different tiers or modules of the application, and the transaction rates is important. "Typical" transactions must be identified, and for each of them the designers must specify the potential users (Table 1). Part of this information is taken through traffic analyzers and other software, permitting data traffic capture on a per packet basis.

	Transaction type	Request (Bytes)	Response (Bytes)	Transactions/sec
Distribution Center	Inventory lookup	350	300	10
Sales Representatives	Sale	350	500	20

Table 1: Application planning: traffic details for "typical" transactions.

Although it is better to collect this information from real users running the applications with actual requests and replies, in many cases, it is neither easy nor prudent to do so. Therefore, instead of actually deploying the new application, the designers install actual servers but use client application emulators to replicate real network conditions. This is usually done in a separate test bed network, in order to test each application and quantify its needs in terms of throughput and response times. Because this kind of testing is relatively expensive in terms of resources, designers frequently opt to use simulation instead of test bed networks to estimate the data.

Finally, network designers characterize the transactions that each application can generate and the potential users of each transaction, effectively describing the workload that each application will place on the network. Then they project the quality of service level that new application users will find acceptable, and use this as a benchmark for evaluating the results of the next step, capacity planning.

Capacity Planning

Capacity planning is the final phase of an NRP study. It is mainly concerned with evaluating network performance under different application usage scenarios. For example, capacity planning is used to detect problems in a hypothetical network by employing "what-if" analysis in order to identify likely problems. Of course, "what-if" analysis can be used to evaluate already built networks. Moreover, network designers can assess the impact of the introduction of new applications on an existing network, and establish future resource requirements [1]. Designers test the network under a variety of conditions, using the data collected in the previous steps of NRP, and experimenting with different parameters and/or topologies. In other words, capacity planning aims at predicting the future behavior of the network under several workload scenarios. Among the issues that designers normally have to address is whether new investments in network infrastructure are needed, and if the network has untapped reserves that are not effectively utilized.

Capacity planning investigates the performance benefit from expanding network segmentation, introducing load balancing and caching, or modifying link capacities. Network segmentation involves separating certain portions of network traffic for performance, security or reliability reasons. Load balancing in key network components can improve availability and performance. The study must name areas where load balancing should be introduced. If load balancing is already employed, then one has to examine if any modifications are needed due to changes in usage patterns. This information may help to implement more effectively new and redundant paths throughout the network. Next, designers consider whether caching is appropriate for the applications involved. If deemed so, then caching can reduce both the workloads introduced into the network and the average response times. Caching may also reduce the level of proposed investments in new infrastructure.

If the above modifications do not allow the network to meet the NRP objectives, then the designers must consider adding or upgrading network resources: Increasing link capacities, upgrading network servers, replacing old routers, and so on. Capacity increases are performed mainly on the network elements spotted as performance bottlenecks. Capacity increases usually cost the enterprise significantly more to than the previously mentioned measures, but sometimes this is the only way to meet the quality of service level targeted.

Although the above are by no means an exhaustive list of the techniques used for improving network performance, they are indeed the most commonly used to obtain a higher level of quality of service. Note that network designers always consider deploying the most recent versions of network protocols in order to increase efficiency. For example, efficient, up-to-date implementations with the latest TCP modification proposals can lead to significant performance improvement. The same applies to, say, employing HTTP/1.1 [5] instead of HTTP/1.0 in all web servers and browsers in the organization [21]. Nonetheless, certain legacy systems may require the presence of older protocols or even entire protocol stacks. This introduces an additional challenge because this need for backward compatibility leads to more complex and less flexible network designs.

After determining the best strategies to meet the target quality of service, designers can model the network using mathematical methods to obtain exact solutions, provided that the number of network elements is not large and their corresponding relationships are simple. However, most real networks are too complex to be accurately studied with analytical models, and simulation tools are used instead.

When using simulation to perform capacity planning, one must produce representative workloads to test the behavior of the network. This is where the traffic characterization performed earlier starts to bear fruit, since it is important to model the network as accurately as possible. Several studies have investigated the issue, attempting to define workload generators that model actual traffic [2 - 4, 16 - 19]. Fischer and Fowler [6] have compiled a matrix featuring the results from seminal papers on the topic. We reproduce their matrix in Appendix A.

Using these research results, one can model different applications present in the network, after making some assumptions about the key transactions, and determining what is the best configuration for the network under study. However, this methodology may not be sufficient to capture the side effects in extremely large and complicated architectures. For a more accurate characterization, there are several techniques found in the literature classified according to the nature of the traffic descriptors into the following categories: autoregressive moving average (ARMA) models, Bernoulli process models, Markov chain models, neural network models, self-similar models, spectral characterization, transform-expand-sample (TES) models, traffic flow models, wavelet models, geographic traffic models, and empirical envelopes [19]. Once the characterization is completed, a simulation tool is used to test hypothetical changes, described as "what-if" scenarios earlier.

Simulation is also employed to evaluate the behavior of the network in the future depending on the growth of different parameters, such as the number of users, the frequency of transactions, and so on. After completing the simulation runs, the network designers analyze the results to see if the NRP objectives are met, and choose the most cost-effective design alternative (or alternatives). As stated earlier, all network protocols have their own thresholds of acceptable performance. The simulation results must demonstrate that the NRP objectives are met and that the thresholds are not exceeded.

Conclusion

Network resource planning is a methodology employed to design better networks, upgrade existing ones in a cost-effective manner, detect and solve performance problems in large and complex network architectures, and ensure that networks achieve a certain quality of service at minimum cost. Network baselining, the first step in NRP, provides an accurate picture of the relationship between available versus utilized capacity of the network. Baselining is followed by application planning which collects information about new applications to be deployed in the network. Finally, capacity planning pulls everything together by creating a comprehensive model of the network and providing the optimal network design.

Appendix A

Internet Traffic Invariant, Protocol Level, and Related Probability Distribution Information [6]

Invariant	Protocol Level	Distribution	Parameters
Connection size		Lognormal		[16]
Connection duration		Lognormal		[16]
Requested file popularity	Application	Zipf		[18]
Requested file sizes (overall)	Application	Hybrid: Lognormal body, Pareto tail (Heavy-tailed)	HTML Size Mean = 4-6 KB Median = 2 KB Images = 14 KB	[18]
FTP transfers	Application	Pareto tail (heavy tailed)	0.9< alpha < 1.1	[3]
Number of Page Requests/Site	Application	Inverse Gaussian (heavy-tailed)	Mean = 3 Standard Deviation = 9 Mode = 1	[18]
Reading time/page (sec)	Application	Heavy-tailed	Mean = 30 Median = 7 Standard Deviation = 100	[18]
Sessions (arrivals)	Session	Poisson		[4]
Session duration	Session	Pareto (heavy-tailed)		[4]
Session size	Session	Pareto (heavy-tailed)		[4]
WAN traffic at TCP level	Transport	Self-similar (fractal, multifractal)		[3]
TCP connections / Web Session	Transport	Heavy-tailed		[3]
Interarrival time of packets	Network	Heavy-tailed (LRD, fractal)	Cox model	[3]
Interarrival (generation) time of packets generated by user at keyboard	Network	Pareto (body), Pareto (upper tail)		[17]
Interarrival time of Ethernet frames	Data Link	Self-similar		[2]

References

1

Annette, C., Franklin, D., and McCown A., Network Resource Planning for SAP R/3, BAAN IV, and PeopleSof: A Guide to Planning Enterprise Applications. McGraw-Hill Professional, 1998.

2

Crovella, M., and Bestavros A., "Self-Similarity in World Wide Web Traffic: Evidence and Possible Causes."IEEE/ACM Transactions on Networking, Vol. 5, No. 6, 1997, pp. 835-846.

3

Crovella, M., and Lipsky, L., "Long-Lasting Transient Conditions in Simulations with Heavy-Tailed Workloads". In Proceedings of the 1997 Winter Simulation Conference, December 1997, pp. 1005-1012.

4

Feldman, A. and Whitt, W., "Fitting Mixtures of Exponentials to Long-Tail Distributions to Analyze Network Performance Models," Performance Evaluation, 31, 1998, pp. 245-279.

5

Fielding, R., Gettys J., Mogul J., Frystyk H., Masinter L., Leach P., and Berners-Lee T., Hypertext Transfer Protocol HTTP 1.1, RFC 2616, June 1999.

6

Fischer, M., and Fowler, T., "Fractal, Heavy-Tails and the Internet".Sigma Technology Summaries, 2 (Summer 2001), Mitretek Systems, pp. 11-16. < http://www.mitretek.org/pubs/mitretek-summaries_summer/Sigma_Pubs/Fractals.PDF> (May 2003).

7

IEEE, "Recommended Practice for Software Requirements Specifications." IEEE Std. 830-1998, IEEE, New York, 1998.

8

McKeller, B., Network Baselining, Part I: Understanding the Past to Predict the Future (white paper), Acterna. < http://www.acterna.com/united_states/technical_resources/white_papers/baselin1.html> (May 2003).

9

McKeller, B. Network Baselinning, Part II: The Big Picture (white paper), Acterna. < http://www.acterna.com/united_states/technical_resources/white_papers/baselin2.html> (May 2003)

10

McKeller, B., Network Baselinning, Part III: Focus on the Nodes (white paper), Acterna. < http://www.acterna.com/united_states/technical_resources/white_papers/baselin3.html> (May 2003).

11

Metcalfe, R. "The Internet after the Fad" (interview), Monticello Memoirs, Smithsonian Institution, May 30, 1996 < http://americanhistory.si.edu/csr/comphist/montic/metcalfe.htm#me7> (May 2003).

12

Metcalfe, R., and Boggs, D., "Ethernet: Distributed Packet Switching for Local Computer Networks."Communications of the ACM, Vol. 19, No. 5, July 1976, pp. 395-404.

13

Nametka, W., Network Performance and Capacity Planning: Techniques for an e-business world (white paper). IBM Global Services, 1999. <http://www-1.ibm.com/services/its/us/source/nametka.pdf> (May 2003).

14

Nielsen, J. Metcalfe’s Law in Reverse, July 25, 1999, <http://www.useit.com/alertbox/990725.html> (May 2003).

15

Oppenheimer P., Top Down Network Design. Cisco Press, 1998.

16

Paxson, V., "End-to-End Internet Packet Dynamics." IEEE/ACM Transactions on Networking, Vol. 7, No. 3, 1999, pp. 277-292.

17

Paxson, V., and Floyd, S., "Wide-Area Traffic: The Failure of Poisson Modeling." IEEE/ACM Transaction on Networking, Vol. 3, No. 3, 1995, pp. 226-244.

18

Pitkow, J., "Summary of WWW Characterizations". In Proceedings of 7^th International World Wide Web Conference (WWW7), Brisbane, Australia, April 1998.

19

Rueda A., and Kinsner, W., "A Survey of Traffic Characterization Techniques in Telecommunication Networks." In Proceedings of 1996 IEEE Canadian Conference on Electrical and Computer Engineering, Vol. II, Calgary, Canada, May 1996, pp. 830-833.

20

Spohn, D., Brown, T., and Grau, S., Data Network Design, 3^rd edition. McGraw-Hill, 2002.

21

Touch, J., Heidemann, J., and K. Obraczka, Analysis of HTTP Performance, ISI Research Report ISI/RR-98-463, August 1998.

Biography

Beatriz Acosta (bacosta@uniandes.edu.co) is an Assistant Professor at the Departamento de Ingeniería de Sistemas y Computación, Universidad de Los Andes, Bogotá, Colombia, working in the area of computer networks, and focusing on network resource planning, design, and security. She has recently consulted for Fondo Nacional de Ahorro and Termotasajero, performing NRP and security analysis studies. She received a MSc in Systems and Computer Engineering from Universidad de Los Andes and a BSc in Informatics from Universidad Rafael Urdaneta, Maracaibo, Venezuela.

Kostas Pentikousis (kostas@cs.stonybrook.edu) is pursuing a PhD in Computer Science at Stony Brook University. His research interests lie in the area of computer networks, including transport and application layer protocols, mobile computing and wireless communications, network and energy management. He received a BSc (Honors) from Aristotle University of Thessaloniki, Greece, and a MSc from Stony Brook University, both in Computer Science.