pointer

Category Archives: VoFI – Voice over Wireless

Wireless Field Day 5: What You Did and Didn’t See…

Last week, we participated in our second Wireless Field Day event and hosted 11 of the industry’s top wireless professionals at our headquarters to dive into demos of our Omni Distributed Analysis Platform 7.5. For those of you who missed the live stream of our presentation, we thought a quick wrap-up of what happened when cameras were rolling – and even when they weren’t – would help you feel like you were in the room with our delegates!

Want to know what went down? Read on, as we give you the inside scoop and what the cameras did and didn’t capture at Wireless Field Day 5.

Capturing 802.11ac Packets in Real Time
Demonstrating a live 11ac capture was one of our favorite parts of the day, as it’s something we’ve been working hard on, and we’re the first to deliver a solution. Although we weren’t using 802.11ac as the primary wireless network, we had a separate laptop connecting to a Linksys 11ac AP and sending traffic over an 11ac network.

We used a 1-steam 11ac WLAN adapter, the Cisco AE6000, to capture 11ac traffic for analysis in OmniPeek. We showed summary-level views of the 11ac traffic in OmniPeek’s Compass dashboard, and drilled into detailed views of the 11ac packets themselves. With OmniPeek’s new support for MCS and spatial stream reporting, all key metrics of any WLAN, including 11ac, are at your fingertips. And with support for 11ac USB WLAN adapters for capturing, you can continue to use OmniPeek as your go-to portable WLAN network analyzer and capture 11ac anywhere, at any time.

Here’s the video of us capturing 802.11ac traffic.

VoFi (Voice over Wi-Fi) Capture
In addition to capturing single-stream 11ac traffic, we also demonstrated packet analysis of a VoFi call, which you can watch us do below. With OmniPeek, we showed how users could capture an entire VoFi call, store it, and play it back to see where problems may have occurred.

By highlighting the specific call in our “calls view” interface, you can easily drill in to see detailed analysis of the call as a whole, including details like the number of control packets, control flows, signaling flows, and signaling packets. And in our “media” view we provide even more details regarding the call, including key metrics like MOS, R-Factor, jitter, and packet loss so you can determine exactly how each and every call on you WLAN is performing.

What you didn’t see…
Well, if you’ve checked out any of the videos, one thing you’ll notice is that there are a lot of Macs among the WFD delegates, and we’re demonstrating from a PC – clearly a technology mismatch. But before the delegates left our offices, many were already running OmniPeek on their Macs (either using Boot Camp or the VM of their choice) AND capturing 802.11ac packets with the very same Cisco AE6000 we used in our demonstration. Needless to say they left a very happy bunch.

In case you missed Stephen Foskett’s original stream of the event, you can catch the remaining videos here. As always, if you have any questions or just want to get some conversation going, leave us a comment on this blog.

Are Your Users Complaining? Pinpoint the Reason with OmniPeek

Try as you might, making users happy with network performance is a difficult task. Sometimes problems arise with applications and sometimes with the network itself. Either way, it is your job to make the end user experience the best that it can be.

Luckily, if you are using OmniPeek, problems of any type, whether application or network, or common or rare, can be easily remedied. Let’s take a look at some common user experience issues and how OmniPeek can help to identify the root cause and guide you towards a permanent solution.

Network Downtime
Fortunately unplanned network downtime is a pretty rare occurrence nowadays, but if it does occur the response must be instantaneous. With OmniPeek you can immediately assess the scope of the outage, from a few specific users to an entire subnet. If distributed, 24×7 analysis is in place, you can rewind the network to see exactly what was going on when the outage occurred, providing the best clues possible for determining the root cause, which in this case is probably equipment failure somewhere in the network path of the effected users.

Not Enough Bandwidth? Find the Hog
Bandwidth issues typically arise not because of a lack of bandwidth, but because a user or users are consuming an abnormally high amount of bandwidth. This is becoming more common with the wide availability of video streaming sources, particularly those that are not work related. The Compass dashboard in OmniPeek is an easy way to isolate bandwidth hogs, allowing you to identify not only the user but the type of traffic, providing the ammunition you need to ensure that network traffic is strictly business related.

VoIP Quality Issues
VoIP is the most commonly used real-time protocol on corporate networks. Given its real-time nature, it is extremely sensitive to network problems like too much latency, dropped packets, and jitter, much more so than “regular” network traffic. For real-time data to be useful, it must arrive in order, and within a few hundred milliseconds of being sent, otherwise it is no longer “real-time” and doesn’t fit into the overall conversational flow. Problems with real-time data will continue to grow as more corporate video is transmitted over IP networks, and as more wireless networks are used for the last 100m of data delivery (voice over Wi-Fi, or VoFi).

From a network perspective, VoIP, VoFi, or video over IP are just data on the network. In order to identify problems with real-time traffic, you first need to isolate the traffic, while still seeing it in the context of the overall network. To do this, you can use the Voice and Video dashboard in OmniPeek to see how real-time traffic is coexisting with the rest of the network. Then, the Calls and Media views will allow you to see a more detailed analysis of the packet-by-packet performance of the real-time flow, including detailed analytical metrics and a bounce diagram so you can pinpoint exactly where the problem is, and compare it with network activity to correlate real-time transport problems with overall network usage.

If you are experiencing another kind of reoccurring issue on your network, please leave us a comment and we’ll address best practices for remedying this issue.

Q&A: How Can I Ensure the Best Application Performance?

The network is often blamed for poor application performance, even if the network is not the culprit. Network engineers therefore need to know how to determine the cause of the problem, even if it’s in the application itself. Below, you’ll find the most common questions we get from our clients on this topic, and how you should address them – whether you’re working with wireless or in a cloud environment.

Q: How do you know if it’s your network or your application?
A: This is the first question you should figure out when users are complaining about a poor application response time. We’ve gone into great detail on this subject, but here are some initial indicators to help you prove that the network is not the culprit:

Packet-level monitoring will show you the conversation between a client and a poorly performing application. If a user request is followed by a quick network acknowledgement (ACK) but a delayed data response, it means it is an application issue. If the ACK is delayed or missing, then the network is to blame. You can get this information clearly visualized in OmniPeek’s Compass dashboard, using the “2-Way Latency” setting, which displays the network and application latencies, with drill-down on a per-node or even per-flow basis.

If you’re streaming Expert events into a log management system, network issues are shown through slow acknowledgements, TCP slow segment recovery, slow and frequent re-transmission, and low throughput. Application problems manifest in slow application response times.

Q: Does application monitoring change in a virtual environment?
A: While network monitoring may be more difficult in a virtual environment due to the introduction of overlay networks and virtual switches which often aren’t controlled by the network team, the fundamental analysis techniques are still valid. A capture only has to be in the packet path between the client and the server in order to get diagnostic info and answer the basic question: is the problem in the network or in the application?

Q: How should I address application problems if they are housed in a cloud environment?
A: Cloud is generally hostile to packet capture, since there’s no network visibility if you don’t control the network. In this environment, we recommend focusing on the end user experience. If there are complaints or concerns about the application performance, capture on a client machine to see what the traffic pattern reveals. We’ve found that many of our customers appreciate using the OmniPeek Remote Assistant capture agent, as it’s a lightweight capture tool with a simple user interface to capture packets from a Windows client. The encrypted capture file can then be sent back to the network team for analysis.

Q: How should I handle issues with real-time applications like VoIP?
A: Sadly, with VoIP it often is a network problem. Latency is often the root cause. Sometimes it’s a transitory problem, like routing reconvergence after a link goes down (or up). Sometimes, the packets are simply routed through inappropriate equipment, like a proxy which doesn’t do any VoIP analysis, but which still adds latency.

There is a pair of tools we recommend for VoIP. First, use the built-in VoIP analysis in OmniPeek Enterprise to measure the MOS scores and determine how widespread the problem is. Second, use Multi-Segment Analysis (MSA) to capture at multiple points simultaneously in the packet path, to determine whether there are any significant sources of latency in the network, and where they are.

Q: How do you know if application performance is sufficient?
A: This is subjective to the end user. We usually suggest examining the application response time. This measures the time it takes an application to respond to a specific user request on a per-request or per-flow basis. The Expert dashboards in OmniPeek and OmniEngine Enterprise will give you these numbers very easily.

Our products also assign one of three basic levels of performance: satisfied, tolerating and frustrated. We dive into deeper detail about how you should measure and report this here.

Q: What if my application has a bug in it? How do I know and how should I solve the problem?
A: Once you’ve demonstrated that there is a problem in the application, the next steps may not be obvious to the sysadmins or developers. Most modern applications are highly modularized, split into multiple layers across many different servers, and if a back-end service is slow to respond, that delay will propagate all the way to the user. Packet capture can provide insight here as well: use the application performance analysis techniques on a capture taken on the front-end server to see whether there’s a dependency on other servers, and what the application response looks like from those remote systems. This works even if the connections are SSL or TLS encrypted, as it will be clear which packets are simple ACKs and which are application-layer responses. Repeat until you find which server in the distributed application is causing the major slowdown.

As always, please let us know if you have any additional questions!