pointer

Monthly Archives: April 2010

Can your Network handle Telepresence?

Telepresence is a big hit in the business world. For good reason too, not only does it provide unique and sophisticated remote collaboration but it’s inexpensive and more environmentally friendly. Enterprises are quickly discovering the business value in telepresence as it transforms conferencing into a lifelike and immersive experience with high-definition video, life-sized video displays, high quality sound and unobtrusive cameras and microphones. Cisco, who owns the mindshare around telepresence, couldn’t be more pleased.

With the technological benefits of telepresence comes the responsibility in making sure networks can handle the demand. Monitoring the network is critical as it carries the service for telepresence.

In terms of network strain, video is much more demanding than VoIP. VoIP expects regular delivery but video does not as it largely depends on movement and what is going on in the environment. Video is much more bandwidth intensive as well as more sensitive to latency, jitter and packet loss. In fact, below a certain quality threshold for video it is nearly impossible to see anything.

Organizations should understand their current baselines and network in preparing for telepresence. Key metrics include travel levels per segment, packets per second and packet size distribution. Also be aware of what the traffic level is per application including average rates, peak rates and weekly patterns. With this depth of understanding of network performance, organizations can better scope telepresence computing needs and validate network configurations.

There are three points to consider when implementing telepresence in a network environment:

1) Success breeds success

In order for employees to accept a new technology and adopt it fully, the initial experience using it has to be successful. Beat the outset; be diligent in terms on network analysis as this is when user opinions are formed. Expect the demands to be extreme when first introducing telepresence into the organization.

2) Success increases network demands

The more people that are using the successful technology, the more demand on the network. It’s important to stay in tune and not assume a certain baseline status will be reached. Network needs will constantly change depending on load.

3) Interoperability is key

Ensure quality across networks segments you don’t control. When monitoring and optimizing the quality of your network, try to reach for the best quality at the end point and don’t settle for the lowest common denominator.

Telepresence can provide an organization a lot of advantages and benefits provided the network is designed to handle it. In short, don’t compromise on what’s under the hood – the network and tools to keep it humming. Otherwise, your telepresence deployment will be remembered as an expensive mistake.


What is a NetFlow Analyzer?

Before we address this question, we must address an even more basic question “What is NetFlow”? NetFlow, and other flow-based technologies like sFlow, JFlow, and IPFIX, are simply specifications for collecting certain types of network data for monitoring and reporting. The data sources are network devices themselves, like switches and routers, the idea being to leverage existing resources in the network to provide data that is for the most part already being processed by these devices. To that end, flow-based systems provide an economical source for network monitoring data.

All flow-based systems start with flows as their basic element. A flow is a sequence of packets that has the following seven identical characteristics: source IP address, destination IP address, source port, destination port, layer 3 protocol type, TOS byte, and input logical interface. By definition, a flow is unidirectional. Flows are processed and stored by supported network devices as flow records, and it is these flow records that vary from specification to specification - i.e. a NetFlow flow record does not take quite the same form as an sFlow flow record. This requires different parsing and processing techniques for each flow-based specification. It is at this step where flow records are consumed and the term NetFlow Analyzer is introduced.

Basic flow analysis is a multistep process, requiring several different elements to be present. Packets enter a switch or router, just as they would as part of normal network operation. If the network device is flow-enabled and the feature is active, additional processing will take place to identify individual flows in the packet stream per the seven characteristics mentioned above. Depending on the configuration of the network device and how busy the network is at any given time, this processing may be done on every packet, or just a sampling of the packets. As flows are identified, flow records are created per the specification supported by the network device, for our purposes NetFlow, and the records are stored locally in the network device. As flows are completed, the records associated with those flows are exported to an external NetFlow Collector, where they are archived for further analysis and reporting. Once the flow record leaves the network device it is deleted from memory to make room for other flow records. Though efficient since the packets already must be processed by the network device, NetFlow does put an additional strain on the network device since it requires additional processing beyond that required for only switching or routing, and it requires additional storage on the switch for the flow records being processed and exported.

netflow_analyzer_blog.png

A NetFlow Analyzer includes the NetFlow Collector, which accepts and stores the completed flow records; a storage system to allow for long-term storage of large volumes of flow-based data; and analysis software to mine, aggregate, and report on the collected data per user requests through a customized UI, often web-based but sometimes client-server. The NetFlow Analyzer can be software-only or appliance-based, but most systems are appliance-based, and the system often includes multiple appliances.

So what are the advantages? NetFlow data comes “for free” from NetFlow-enabled network devices, eliminating the need for additional network probes to collect the flow-based data. But remember, it’s not entirely free since it requires processing and storage resources on the network device thereby competing with the prime directive of the device – route packets. Given the 7 characteristics of a flow, NetFlow Analyzers can provide a relatively detailed set of network performance data, and given enough storage this data can be archived for quite a long time providing a long-term record of network behavior.

But there’s no such thing as a free lunch. NetFlow Analyzers may not always be 100% accurate since the source of the flow data can be from sampling and not an analysis of each and every packet. NetFlow Analyzers also create additional network traffic moving flow records from the network device to the NetFlow Collector, possibly impacting performance on an already busy network. And NetFlow Analyzers can report on nothing more than the information they can interpolate from the 7 flow characteristics, making them excellent network monitors but poor network analysis solutions because they often lack the data to perform root-cause analysis once a network anomaly is detected. Network analysis systems that derive data from independent

interrogation of each an every packet, like the OmniPeek Distributed Analysis Solution, provide all the data necessary not only for detailed network reporting, but for advanced, root-cause analysis as well. No sampling, no need to move data across the network for storage and analysis. All analysis is done at the source, by tapping into a network device and processing all the data locally.

Each system has its place, but when the time comes for root-cause analysis, and it always does, a packet-based analysis solution like the OmniPeek Distributed Analysis Solution is what you need.

VoFi Analysis: Get Started with our Guide to VoFi Monitoring, Analysis, and Troubleshooting

Online mobile VoIP (or VoFi) is coming. In-Stat anticipates 171.3 million users by 2013, with annual revenues projected at $10.8 billion (“Mobile VoIP – Transforming the Future of Wireless Voice; In-Stat In-Depth Analysis,” Frank Dickson, Sept. 2009). Previously on our blog we’ve talked about why VoFi and why now, specifically the benefits of VoFi. Now we’ll focus on VoFi monitoring, analysis, and troubleshooting.

Before you panic, take a deep breath. Analyzing VoFi traffic is basically the same as analyzing VoIP traffic. Remember though that wireless exacerbates factors such as jitter, latency, and packet loss that affect VoIP. Watch Using VoIP Metrics to Identify Network Problems for the specifics.

Begin at the Beginning: Your End User’s Call

When problems arise with VoIP or VoFi applications, you start in the same place. Your first step – before you begin to worry about statistics or packets – is to take the time to listen to representative calls. You want to hear what your end users are experiencing. Your ear will reveal telltale signs of latency, jitter, and packet loss. Be sure your VoIP analysis application supports playback of call audio, specifically the playback of individual RTP streams as well as the playback of the complete call. Without the audio, you can spend hours tracking down problems that aren’t due to either the application or the network – for example, clicking due to a damaged handset.

Take Your Network’s Pulse

Once you have listened to the call, you’ll want to take a look at what’s going on in your network.

33.png

Figure 1: Overview of Network Health

Immediately you see what you heard – the call quality was poor. The Mean Opinion Score graph gives an average over all calls occurring on your network. In this example there’s just one call, so you see the average for the duration of that call.

Dig Deeper

With Expert Events you’re able to verify what your ear told you.

3.09.png

Figure 2: Event Summary

With this call, you can see that there are a lot of physical errors: late packet arrival, retries, out of sequence packets, packet loss, excessive jitter, and more. With the cause identified, you can quickly begin to fix the problem. Looking at the call in its entirety, you’ll notice the call is closed, it had a successful ending – meaning the call wasn’t truncated – what CODEC was used, how long it was, and what the Mean Opinion Score was.

3.43.png

Figure 3: Call Statistics

In this example, the mean opinion score of 2.5 lets you know that the quality of the call was pretty poor. In the media view, you can drill down into each segment leg to determine why the quality was poor.

5.11.png

Figure 4: Call Details – R Factor, Mean Opinion Score, Packet Loss Percentage,
One Way Delay, Etc.

Understand the Differences between Wired VoIP and VoFi Calls

The next two figures show both a Wired VoIP call and a VoFi call packet-by-packet. (For an in-depth discussion of these calls, watch Anatomy of a VoFi Call: Packet-by-Packet.) You’ll notice that they’re pretty similar. The protocols used are different and with VoFi there’s the additional
step of authentication.

vofi_post1.png

Figure 5: The Anatomy of a Wired VoIP Call

The differences involve: wireless segments instead of wired segments; signal interference; and wireless roaming.

vofi_post2.png

Figure 6: The Anatomy of a Mobile VoIP (VoFi) Call

Learn More

Last week in Toronto, Joe Habib, Director of Global Services, presented “QoS of IP Telephony: Slaying the Three-Headed Beast of Jitter, Latency, and Packet Loss” at IT360. His presentation (PDF) is now available online. If you’re interested in ensuring QoS for your current (or future) VoFi deployment, you should definitely check it out.

In the presentation, you will learn:

  • What six factors contribute to poor voice quality
  • How to establish metrics for evaluating VoIP call quality
  • How to balance high-speed, bursty data requirements with
    requirements of high quality voice calls
  • How to capture data for VoFi Analysis and use VoIP metrics
    to identify developing problems
  • How to analyze a VoFi call packet-by-packet and verify voice
    quality with call playback