By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Oftentimes I am asked, "why do you want to know what is going on in the traffic flow of a network? What's the point? Why doesn't utilization alone cut it?" In response, I make one of the most traditional traffic analogies on the planet that nearly anyone who has ever been stuck in rush hour traffic can relate to: Network engineering and design is very much like the road network.
Civil engineers that design today's roadways also have to understand certain characteristics of the traffic in their designs, so why would it be any different for network engineers designing the application roadways? How many times have you been stuck in traffic due to construction? Or detoured to a new route due to a water main break? Some of these things are not predictable or unavoidable. But some traffic patterns are known and even nicknamed. This article is geared toward showing parallels between the two worlds of traffic flow analysis for people who want to understand more of the characteristics of why application traffic flow is such an essential piece of knowledge for engineering a network.
Avoiding rush hour
Let's first talk about the dreaded phrase, rush hour. No, I'm not talking about the comedy starring Jackie Chan and Chris Tucker. I'm talking about the hours in the day, Monday through Friday, where traffic volumes on the major freeways and intersections are so congested that people walking on the sidewalk are going faster than your car. For each metropolitan area, this rush hour tends to depend upon certain conditions. But in general, 7 a.m. to 9 a.m. and 4 p.m. to 6 p.m., Monday through Friday, tends to be the highest traffic rate for all of our cities' freeways, with the exception that rush hour tends to start about 2 p.m. on Fridays in Dallas for some reason.
Consider the analogy that a large freight and trucking company is in charge of delivering a large number of trucks with merchandise to a warehouse downtown in the shortest amount of time possible. Would the trucking company expend the dollars, pay double for gas, and make 100 trucks sit in rush hour traffic if they could avoid it? Absolutely not. They're in charge of scheduling their deliveries to the warehouse on a weekly basis, so they would put together their 100 trucks and ship them through the roadways at "off peak" hours when traffic volume tapers off.
The same situation occurs on application networks and backup routines. For business-critical applications that need to be backed up on a daily or weekly basis, either incrementally or fully, the backup team has to schedule these transfers. For application networks, the business day tends to be the rush hour. So backup teams should schedule their high-volume backups during the offline hours or stagger them throughout the day so they do not overload the network. Backup applications can easily saturate a network if not scheduled appropriately.
The carpool lane and QoS policies
What about the essential applications that cannot be scheduled but also need to occur during rush hour? Well, that's where QoS (Quality of Service) policies come into play. On today's roadways, the creation of high-occupancy-vehicle lanes allows multiple-person vehicles to be prioritized and get through traffic faster. This is designed as an incentive for reducing emissions in the air. The same sort of incentives for applications considered special may be provided for in today's computer networks.
For example, voice over IP (VoIP) applications have special requirements and need a different priority queue. Also, any business-critical application like order processing would take priority over basic Internet usage. So now, instead of having one lane of traffic for all of the applications, various lanes (buffers) are created to allow more important items to get through the network faster. Additionally traffic signals designate which applications or flows may have access to the roadway first. These traffic signals tell the applications how to behave and in which order they can use the circuit at any given time.
What about other traffic conditions? How many times have we driven over the traffic counters laid out by civil engineers? I do it often. Well, actually the technology for application traffic flow is a little bit more sophisticated. Using accounting policies like NetFlow, continuous monitoring solutions allow network engineers to diagnose changes in the traffic flow dynamically. In virtually real time, NetFlow data in reporting solutions can tell a network engineer what "cars" are traveling on what "roads," where they're going and where they've been. This allows the engineers to do traffic reports much like those broadcast over the radio.
These traffic reports are key to conditions on the network. It lets the users know what kind of delays to expect. For example, if there's wreck on Highway 6, then the drivers expect to be slowed down and delayed. In applications traffic flow, if a circuit is congested and traffic is slowed down, an application slowdown due to congestion delay is expected. Additionally the network engineers are aware of the issue and understand it. Quite possibly they would also be able to do something to reduce the congestion during those periods to increase the performance of the network. Perhaps one of those backup jobs is going on and could potentially be rescheduled. Without that visibility into the network, engineers wouldn't know what to tell users about the application slowdown.
Traffic reports also tell users whether or not certain traffic routes are available and the roadway conditions on given routes. If there is construction on Interstate 10, the traffic report announces the alternate routes. The same analogy applies to application networks. If a certain circuit is down, the alternate routes are made available until the circuit's connectivity can be restored. The reporting allows network engineers to know about inactive circuits (and hopefully restore them) if some sort of failure occurs. With the NetFlow data, inactive circuits are alerted to the users and network engineers are notified about outages. Additionally, in the same way that weather affects roadway conditions, outside elements can affect application traffic flow. For example, in applications traversing the network, a satellite uplink might be used as an alternate route which increases the overall latency of the application. This would certainly slow down the applications like rain on the roadway slows down traffic.
Speed limits and bottlenecks
Having a good understanding of the network also allows engineers to address bottlenecks. For example, link speeds are very much like speed limits. The speed limit defines the fastest rate cars can travel down that single link of roadway. In the same way, link speed determines the fastest rate the application packets can traverse a circuit. By increasing the speed limit, it doesn't necessarily mean that more cars can travel down the roadway faster. If there are not a lot of cars on the roadway, the speed limit increase doesn't really affect the ability of a car to reach its destination faster. But strategically affecting the speed limit will help in certain cases. Similarly, circuits and new connections can be designed and engineered to allow users to make applications behave better and faster.
Like today's roadways, application traffic flow analysis yields great insight for network engineers and users about the behavior of applications. Would you want civil engineers designing roadways and freeways without having an understanding of what traffic flow is like? Would you want them not to know about construction projects that cause outages and delays? I don't think so. No one tolerates civil engineers who build out massive freeways to desolate places. So why would you tolerate an application network that doesn't have any visibility into the applications flowing over the network?
Lindi Horton is a performance engineer for NetQoS and the network administration expert for SearchNetworking.com.