Why Traffic Reporters Don’t Report from Inside the Car

The next time you’re stuck in a traffic jam, consider how similar the freeway system is to your VoIP network.  You are data inside a packet (car).  You’re trying to get to and from work each day, in real time.

 

Since you’re inside the car, you have little or no ability to see further down the road to determine if you’re going to hit a roadblock or traffic jam.

 

A packet analyzer would be similar to a toll booth where all traffic passes through and the toll taker looks inside the car to determine the occupants.  The toll taker has the same limitations as you: They cannot see further down the road to help determine if you’re going to encounter a problem.

 

Some VoIP troubleshooting tools will send test cars on the network to see how long it takes to get from one location to another.  Again, this doesn’t help locate where the traffic jams are, or what caused slowdowns.

 

In order to locate problems on the freeway system, traffic reporters determined that they needed to get out of the car and get an eagle’s eye view of everything.  From an airplane, they can see all of the intersections, collisions, and traffic conditions everywhere.

 

Freeway agencies determined that they could not afford to keep traffic copters in the air 7x24x365, so they developed systems that gave them the information continuously with a low operational cost: Traffic loops and freeway cameras.

The traffic loops and cameras were deployed throughout the freeway system so if there is a slowdown of traffic, they could quickly use a camera to see what the problem is and remedy it.

 

On a VoIP network, if you want to use a packet analyzer (toll booth) to see the condition of the network, it’s not going to provide you with enough information to solve problems (but it will be easy to determine how many cars have velvet interiors!)

 

If you intend to use simulated traffic (test cars), you’ll also be stuck with a lack of information as to where and why the VoIP network is not performing correctly.

 

Most all networks have built-in traffic loops and cameras on all interfaces.  Managed switches and routers have been deployed far and wide, but little analysis has been done to collect and analyze this information due to the complexity of SNMP.

 

PathSolutions’ SwitchMonitor breaks through this complexity by providing you visibility into the performance of every network interface.  Sources of traffic jams and packet loss can be quickly and easily remedied because the right information is available to you whenever required.

 

Get out of the car, and into a vehicle that is capable of seeing the big picture of your network: SwitchMonitor VoIP.

Advertisements

4 Responses to “Why Traffic Reporters Don’t Report from Inside the Car”

  1. douglas Says:

    Although you don’t say, I assume SwitchMonitor uses SNMP to gather its statistics. If so, it will miss aggregate problems such as contention or poor VoIP based on Jitter, for example. Using SNMP counters generally misses relevance from one packet to the next, something only a protocol analyzer can do. I find each has its place, with some small overlap in functionality between the two.

  2. pathsolutions Says:

    True, SwitchMonitor uses SNMP to collect its information. The problem is that jitter, latency, and loss (the three cuplrits that cause 99% of VoIP issues) all come from certain locations in the network.

    You can’t debug packet loss with a protocol analyzer: You just see that there are packets with non-sequential packet IDs. You aren’t able to use it to find where or why the packets went missing. That’s why you need to look at a lot of router/switch interfaces to find where the packets went missing, then look at the interface stats to try to determine the specific error.

    You can’t debug the cause of latency/jitter with a protocol analyzer: It will simply show you the symptom “There IS jitter” or “There IS latency”. To find the source and cause of the jitter and latency you need to look at the switches and routers to see if a router is flooded, or is overflowing its buffers.

  3. douglas Says:

    I still have to disagree. If you know there IS jitter, with an analyzer you can drill down on that station (or phone) and see what are the characteristics of the packet stream and what else was happening on the network when the situation became known – all things that cannot be seen from packet and byte counters. As noted, SNMP cannot show packet level relevance based data such as Gap Density, Burst Density, Packets out of Order, or Codecs used. Any commercial grade analyzer can also show lost packets within a VoIP stream. Knowing the number of packets flowing through a switch port will only show a problem if it is grossly overloaded. Even if a switch port it overloaded, with almost every Codec used today, the amount of bandwidth needed for a VoIP call is insignificant compared to available throughput on a 100 MB or 1000 MB link.

    Additionally, things like real-time and historical actual MOS scores can give you an idea of trends and usage cycles – all things that cannot be seen from SNMP. For example, did a backup start in the middle of the day (everyone’s MOS scores started to trend down) or did just a group of users see a trending down in MOS scores (someone inadvertently forgot to set the QoS when moving or installing a group of phones)?

    It is our experience that utilization is rarely the cause of poor VoIP quality – we see things like lack of QoS or change in QoS, improperly matched Codecs, and most commonly network contention as the most important factors to look out for. Just viewing counters of packets, bytes, and aggregate errors for a port does not tell you what type of traffic it was – maybe bit-torrent is snuffing out VoIP, for example. There is place for simple SNMP counters, but they do not provide the detail true analyzers can.

  4. pathsolutions Says:

    Sadly, many people put far too much weight into MOS scores. Most all industry experts have identified MOS as a “score that’s nice to know, but does absolutely nothing to help find and resolve the actual problem”.

    The same goes for inter-packet delay, gap density and burst density.

    We’ve seen many of our customers get this kind of information and then have to purchase SwitchMonitor VoIP because it gave them no information on WHERE the problem was coming from, or WHAT caused it.

    I agree that there is a time and place for sniffer/analyzer based solutions, but there are some serious limitations they have:
    They only monitor from one perspective on the network (you have to move it around or have multiple deployments to get more visibility)
    SPAN ports cut their actual usefulness in half (can’t see fragmented packets, runt frames, or other data-link layer problems because SPAN ports don’t typically forward bad/corrupted frames).

    If you are looking to solve a layer-3 problem then analyzers can be useful as you mention: You can identify an incorrect codec or out of order reception problem.

    If you are looking to solve a problem caused by the data-link layer, you need SNMP.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: