The challenge of calculating required bandwidth is as old as the science of networking itself. From the earliest days of telephony, designers were faced with the task of predicting user-base growth and demand, and making the tough economic choices to build their networks appropriately while remaining fiscally conservative.
Despite the tremendous advance of technology and integration, these challenges remain with us today. And, unlike the world of telephony, where a simple erlang calculation would provide the designer with an accurate means of specifying architectures, the modern telecommunications network must contend with far more variables. Consider a few of the most common factors influencing the need for increased bandwidth:
- Network designers are faced not only with a varying number of users on their networks but also by applications and services that require ever-more bandwidth.
- Data file sizes continue to grow, and the network engineer cannot trust that the sum of the user base will know how to minimize file sizes before sending them. For example, current digital cameras can easily generate files exceeding 8M per photo. Do the end users know how to convert those images into Web-ready files of smaller size before they send them?
- Most users will routinely send files via email. When the attached file is sent in an email, the attachment is handled via MIME (Multipurpose Internet Mail Extensions), the underlying protocol that allows the attachment and transmission of non-ASCII information, among other functions. However, an often neglected feature of MIME is that the protocol will use as much bandwidth as it sees available.
- VoIP places an additional load on infrastructures that may originally have been designed only for data. Because different VoIP systems use different CODECs -- and different bandwidths -- a full understanding of the voice traffic must exist before accurate bandwidth predictions can be made.
- As they continue to be deployed, videoconferencing and surveillance applications will add their share of data to the network burden.
- The increased network load at the beginning and end of the workday (when there are multiple email users at one time) will often be three to four times higher than during non-peak periods. Although email is not a streaming, time-sensitive form of communication, user expectations remain high when it comes to network performance.
Lowering bandwidth requirements
Various methods have been devised to lower bandwidth requirements on the WAN, most of which are entirely complementary; thus, their benefit is cumulative. These include:
- Server-side computing
- Data caching
- Data compression
- Latency mitigation
- Loss mitigation
All of these methods can lower the bandwidth requirement for the WAN, but they all carry intrinsic costs in initial deployment and ongoing management. These costs should be balanced against the cost of adding bandwidth.
Recent trends in last-mile connectivity options can bring a substantial benefit. In heavily urbanized areas, buildings are increasingly reliant upon a fiber-optic ring, meaning that circuits up to 100M and beyond are easily attainable. For the enterprise in areas not serviced by fiber, a traditional TDM circuit architecture (e.g., T1, DS-3) or wireless are the only viable alternatives.
ISPs offer "burstable" services, where a given circuit type is supplied to the site, with separate pricing for both the nominal speed and the maximum burst speed. The ability to handle demand is a welcome feature, though cost for such bursting traffic tends to be relatively high.
Best practices
So, given all of these factors, what constitutes a best practice when estimating current and future bandwidth needs?
Here are some suggestions:
- Use one of the many tools available to assess the current utilization of both your LAN and WAN network segments over a period of time. Network monitoring tools can range from open source freeware applications to Enterprise applications capable of monitoring a global network.
- Define what applications are in use today, and by which user groups. Having done so, assess how much bandwidth each application requires, and for what periods.
- Gain a complete understanding of the number of network nodes that contribute to the total. These nodes may include -- among others -- workstations, shared printers, servers, VoIP phones and cameras.
- Summing the average bandwidth per node/node type and multiplying that amount by the total number of nodes will yield a passable estimate of the required bandwidth, +/- 25% or so. Recall that this figure cannot take into account any heavy bursts of traffic resulting from multiple VoIP calls in use, MIME attachments, congestion re-transmits, and so on.
- Determine your nominal oversubscription rate. Consider peak requirements. There will actually be periods when network traffic is much lower. In data-only networks, a 4:1 or 3:1 oversubscription can yield cost benefits without affecting the perceived performance of end users. For networks with higher file-sharing or streaming media, 2:1 is a more realistic figure.
- Assess what applications will be used on the network within a period of 18-24 months and what burden each will place on the bandwidth requirement. Ensure that the connection offered by your ISP contains ample provision for growth.
- Factor in any ameliorating effects from planned or existing systems such as data compression, caching, and so on.
The recommendations above are, of course, only a guideline -- there is no method for achieving a perfect, irrefutable figure for scaling bandwidth. In the end, the network engineer must rely on available metrics, common sense, and the ability to achieve a balance between cost and performance -- and must set the expectations of end users within these limits. Such planning remains as much art as science.
About the author:
Teejay Riedl is the director of corporate training at Telkonet Inc.
