By dividing your network into smaller, interconnected segments, you can increase throughput by reducing competition
Brett Husselbaugh
Your network is probably considerably less efficient than it could be. Dividing it into smaller subnets can significantly enhance performance in most cases. Segmentation is one of the most important but least understood aspects of a highly tuned network.
To segment a network is to divide it into two or more physically independent
competition domains
. Consider the figure "
Network Segmentation
" which shows a token-ring network before and after segmentation. In its original, single-domain configuration, all seven nodes had to compete for the single token serving the network.
Now look what happens when the network is segmented into three sepa
rate competition domains, or rings--one for the server, one for three workstations, and one for the other three workstations. After segmentation, the worst-case scenario is three workstations competing for a token, and there are three tokens serving the network. Of course, you have to add an extra piece of equipment--the bridge that connects the three rings. Network segmentation requires one or more internetworking devices, such as a bridge, a packet switch, or a router, to connect the segments into a single logical network.
The Bandwidth Misconception
Network performance is most commonly quantified in terms of bandwidth. However, using bandwidth techniques to predict network performance is fraught with inadequacies. (See "Misusing Bandwidth" in the December 1994 BYTE.) One particular problem with bandwidth is its failure to take competition into account.
For example, say you have a new network application that you want to roll out to 40 users, although you don't expect
more than 10 to ever be using it simultaneously. Before you install it, however, you want to make sure that the application won't overload the net and bog down total throughput of your 16-Mbps token ring. So the first thing you do is to take a series of measurements with a network analyzer, and it tells you that one workstation will demand an average throughput of 51.2 Kbps. If you're still thinking in terms of bandwidth, you can make the following calculations:
10 simultaneous workstations x 51.2 Kbps = 512 Kbps
512 Kbps x 8 bits per byte = 4.096 Mbps
4.096 Mbps requires only 25 percent of a 16-Mbps bandwidth
Therefore, you conclude that your 16-Mbps token-ring network will comfortably sustain the required traffic. Unfortunately, bandwidth doesn't tell the whole story. Keep this example in mind, and later on we'll compare it to a far more effective method for predicting network performance.
Competing for Queue Space
Queuing theory is a branch of
mathematics that grew out of telephone traffic studies conducted at the beginning of the twentieth century. It is used extensively to model packet-switched as well as circuit-switched networks. Because it handles the probabilistic nature of communication systems, queuing theory is an effective tool for network analysis.
In its simplest form, a queue is nothing more than a place where things can wait their turn for service. The line at the bank and a network computer's incoming-packet buffer are both examples of queues. A queue will have one or more servers (not to be confused with file servers), which are processes that move items through the queue. One or more tellers, for example, deal with customers in the bank line, and one or more operating-system processes will service the incoming-packet buffer.
We can further describe a queue in terms of two rates--the rate at which new things appear in the queue for service (
lambda
), and the rate at which things are serviced or removed from th
e queue (
mu
). As lambda exceeds mu--that is, as new items appear faster than they can be serviced--the queue will begin to lengthen. If lambda continues to exceed mu, the queue buffer will eventually be filled, and any additional new items presented for service will be rejected.
We can model a network as a large, distributed queue. The figure "
Distributed M/G/1 Queue--Token-Ring Segment
" shows the concept graphically. Packets wait in a number of packet buffers that are distributed among the various active nodes until the network can service them. The queue's server here is the network's access methodology. In the case of a token-ring network, therefore, the queue's server is the token itself.
Competition occurs on a network because, in general, only one node may transmit on the media at any given time. As competition increases, therefore, each node spends more and more time waiting for the token, until we reach a point at which the wait time becomes far greater than t
he time actually spent transmitting. Using queuing theory, we can quantify the time spent waiting on the media.
Modeling the Network
In analyzing the effects of competition on a segment, we'll focus on token-ring networks. CSMA/CD (Ethernet) performance usually degrades sharply as competition is raised, giving the network administrator highly discernible notice that segmentation is required. Token-ring performance, on the other hand, degrades more gracefully, and it might not be readily apparent that performance can be significantly improved. By modeling token ring as a queuing system, we can study the effects of competition and discover the influence of other parameters, such as packet size. (This example is somewhat simplified. We don't consider either early token release or such windowing methodologies as packet burst.)
We will consider a token-ring segment as a queue model that has the following characteristics: Markov arrival statistics (also called Poisson distribu
ted), generally distributed service times, and a single queue server. (Thus we call this an M/G/1 queue.) Poisson arrival statistics means that packets reach the network from the individual network nodes in a fairly random fashion. Generally distributed service times (as used here) means that, once a packet is granted access, the transmission time follows a uniform statistical distribution. Simply stated, this means that we'll consider that all packets are the same size.
We can determine the wait time in an M/G/1 queue using the following equation, which you'll find in any book on classical queuing theory:
We adapt this equation to the token-ring model by appropriately defining the rate at which packets are generated for transmission on the segment (lambda) and the rate at which packets are serviced (mu)--that is, accepted for transmission, transmitted, and the token freed. We define these parameters as follows:
We need the factor of 2 in the equation for lambda because, in most client/server environments, every packet from a client must be answered by a packet from the server. Also, the factor of 10 in the equation for mu accounts for the 8 bits per byte, plus an additional 1.25 factor for packet overhead and other node delays in the system.
Applying the Model
How can these equations help us tune our network? They can tell us how many segments to divide our network into, and how many nodes to put on each segment, based on parameters that fit the needs of a particular network.
The first thing to do is decide what level of packet demand we're interested in, along with a figure (expressed as a percentage of the total) that represents the number of stations actively transmitting on a network segment. We can plug these numbers into the equation and plot the results against the number of inserted stations on the segment
.
Let's look at an actual example, shown in the figure "
Small Packet, High Composite Rate
." This models the same situation as we used earlier in the bandwidth analysis. In this case, we're showing a 512-Kbps throughput demand placed on the network by a composite set of nodes. The packets are uniform in size, but small, at 256 bytes. Notice how the length of time each node must wait for a token builds to roughly 6 ms before going negative at approximately 20 inserted stations. This means each packet spends 47 times as long waiting for the token as it does actually transmitting its data.
And what does it mean when the wait time goes negative on the plot? In fact, it becomes mathematically undefined at that point, which means that the real-world network becomes unstable and begins to drop packets. This analysis suggests that, if we want to achieve any kind of reasonable performance, we need to limit any segment that we're asking to carry 512 Kbps using 256-byte packets to n
o more than five inserted users.
This is a significantly different conclusion than we got from our bandwidth analysis, which suggested that a 16-Mbps token ring would easily sustain 512-Kbps throughput for 10 users. The discrepancy occurs because the bandwidth-centric analysis fails to consider the effects of competition. And as we can see, those effects can seriously reduce performance by having the workstations waste considerable time just waiting for access to the network.
Now, let's consider another case, where we have the same composite throughput demand as before, but we've increased the packet size to 2080 bytes. The results are shown in the figure "
Large Packet, High Composite Rate
". Notice the difference. Data-transfer efficiency has been greatly increased, since far fewer transmissions are required to move the same volume of data. The result is a stable network right up through 100 inserted stations. Even here, however, although the network is stable, once we g
et to 50 stations the wait time begins to exceed the transmission time, indicating unacceptable performance. Thus, if we wanted to segment this network conservatively, we'd keep each segment down to, say, 30 to 40 workstations.
One obvious point is that competition is greatly influenced by the number of transmissions per second, but hardly at all by the volume of data to be moved. Therefore, when considering competition, it's important to think of throughput in terms of packets per second, not bandwidth utilization and certainly not bytes per second.
Drawing Conclusions
The analysis technique that we've just described should be used primarily as a qualitative aid in understanding just how sensitive network performance is to segment competition. Like all models, this one is based on certain assumptions, but there appears to be a high degree of correlation with observations of real-world networks.
We can draw several conclusions from studying this model. First, incr
easing competition on a network segment increases each user's average waiting time. Since more time is spent in simply waiting for the token, less time is spent in transmitting. Competition has the effect of limiting the amount of available bandwidth that can actually be used.
Second, simply upgrading older workstations with newer technology can create a competition problem where none previously existed. The newer technology is faster and can send out packets at a higher rate. This will create more competition on that particular segment and can result in slower network performance. When upgrading workstations on a large scale, therefore, don't forget to budget for additional network segmentation and the connecting hardware needed to link the new segments.
Software makes a difference, too. Rolling out a new application can also create a competition problem. It all depends on how the application uses the available packet payload and on how much data it needs to move. For example, some database app
lications move data based on the record size of the tables being accessed. For small data records, this can result in very inefficient data transfer and create a significant competition problem.
Software packages that use a windowing technology, such as packet burst, on a LAN or any other shared media can create a serious competition problem. Windowing technology allows a series of packets to be sent in rapid succession, with only a single required response from the destination (typically a server). This can quickly boost competition. For other types of applications, the normal, internal node-processing delays on the server and workstation actually help to limit competition.
One of the most subtly difficult things to understand about network segmentation stems from the seemingly intuitive observation that, since all traffic is generally directed to the same server, it eventually has to funnel down to the single segment that's occupied by that server. So why bother to segment the network? From a
simple, bandwidth-analysis perspective, there's no clear advantage, and segmentation cannot be justified. The bandwidth argument suggests that even with multiple 16-Mbps segments, they eventually have to feed into a single 16-Mbps segment to reach the server. Thus the fastest that data can move is 16 Mbps, and any gains the network might have earned from parallelism will have been lost.
But we have already seen that such bandwidth-centered arguments fail to take competition into account; their simplicity is deceiving. We might almost consider competition to be a parasite that feeds on available bandwidth. It robs a network of usable bandwidth by causing nodes to waste considerable time just sitting around, waiting for the token to arrive. Segmentation, on the other hand, serves to limit competition and thus allows more efficient use of the available bandwidth.
A Continuing Concern
There's no simple, cookbook methodology for determining how to segment a network, and how b
ig each segment should be, because there are so many factors at work. Our recommendation is to measure your current network traffic with a sniffer or other network monitoring device, then perform your own analysis similar to the one described above, using throughput and packet-size data that reflect your own network conditions. This will yield a rough measure of whether or not your network can benefit from segmentation and will indicate the maximum number of workstations you should place on any given segment.
Segmentation is also an important on-going maintenance function that you constantly have to keep in mind when tuning your network. Any given network segment can become overloaded for a variety of reasons: adding new clients, upgrading older technology, rolling out a new application, or introducing windowing or other new technologies. And once a segment is overloaded, competition can drive its performance down dramatically.
So analyzing competition and segmenting your network isn't something
you can do just once and then forget about. Periodically, you need to reexamine the way your network is segmented and make sure that individual workstations aren't spending too much of their time waiting in line.
illustration_link (13 Kbytes)
Segmenting your network boosts performance but requires one or more internetworking devices--such as a bridge, packet switch, or router--to connect the segments into one logical network.
illustration_link (21 Kbytes)
In this model of a network as a large, distributed queue, packets wait in packet buffers distributed among the nodes until the network can service them.
illustration_link (6 Kbytes)
Here data-transfer efficiency increases, because far fewer transmissions are required to move the same volume of data. Therefore, the network is stable right up through 100 inserted stations. However, once we get to 50 stations, the wait time begins to exceed the transmission time.
illustration_link (6 Kbytes)
This illustrates a 512-Kbps throughput demand that a composite set of nodes places on the network. The 256-byte packets are uniform but small, and the waiting time for a token builds to roughly 6 ms before going negative at approximately 20 inserted stations. At that point, the real-world network becomes unstable and can drop packets.
Brett Hus
selbaugh is president of Tobek Computer Systems, a small LAN consulting firm in Dallas, Texas. He holds a master's degree in electrical engineering, with emphasis in telecommunications, and has analyzed many large LANs. You can reach him on the Internet at
wbretth@aol.com
or on BIX c/o "editors."
Break Up Your Network
