AppNeta | The Path

Posts Tagged ‘video services

In the past few years, businesses are increasingly focused on two areas: 1) saving money and resources and 2) consolidation and collaboration of operations. Particularly in technology, this consolidation can be witnessed in the jump in virtual desktops and virtual servers, both of which leverage resource sharing and economies of scale to save on space, power and ultimately, cost and complexity. At the same time, we are seeing more and more technologies standardize their protocols and use of network infrastructures.

Unified Communications and Collaboration is the concept of putting both voice and data on a converged line instead of the traditional method of separating phone and computer networks. Placing both voice and data on the same network line requires constant monitoring of that pipe for cases of unexpected interactions between the increased numbers of applications sharing one path. While helping PathView Cloud customers diagnose their networks, we’ve seen a wide variety of network problems; one customer’s VoIP calls had intermittent downtime and dropped calls, but only during the hours of 5-6 PM! With the help of PathView, we detected that the customer’s IP storage was kicking in and backing up computers at 5pm, the standard “end of the work day.” This increased consumption of network bandwidth and the lack of QoS on voice traffic allowed enough packets to drop, resulting in poor voice quality and dropped calls.

AppView Web

AppView Web

We’ve seen how people often assume that the pipe needs to get bigger in order to handle the extra traffic that will be traversing the pipe when Unified Communications are deployed. This is not always the case.

When you have the ability to do application-specific testing, you can see  both sides of the pipe in order to help you find the location of the voice quality issues, whether the voice degradation occurs from site a to site b or vice versa. AppView Voice gives you the ability to test devices with real voice packets to verify voice quality between offices or between buildings. This can be done with a specified number of voice calls on the line for a specific amount of time, giving you information such as Mean Opinion Score (MOS), packet loss, jitter and many other performance metrics, which give you insight into how the network is dealing with the extra load on the line. Similarly, it is important to be able to monitor out to a specific website, returning performance information such as DNS resolution time and Connection establishment time, to be able to see exactly what your bandwidth needs on for web-based applications.

AppView Voice

AppView Voice

Using PathView Cloud will help you determine whether extra bandwidth is needed or if settings or configuration are to blame for issues (such as setting proper QoS settings on voice packets!). So with the big move to unifying your communications, use PathView to save your sanity and help resolve issues in a much faster and more precise fashion.

It is a sign of the times that I need to clearly define the term “cloud services” if I am going to use it as an entry point to this blog. And since I wouldn’t dare assert my position to be expert enough to properly define this term (any attempt would surely bog down this entire effort), I will turn to the main sources of knowledge of our time…

If I type “Cloud services” into Google, the top response is of course a link to Wikipedia.  The Wikipedia search for “cloud services” gets redirected to “cloud computing” which is defined as:

Web-based processing, whereby shared resources, software, and information are provided to computers and other devices (such as smartphones) on demand over the Internet.

It is nice to see my opening premise is not far off the mark. Simply put, a cloud service is a web-based service that is delivered from a datacenter somewhere, be that the internet or a private datacenter to “computers.” For now, let’s leave the definition of an endpoint alone.  I know that is a big reach, but this is my blog, and it really isn’t the point.  The point is that for all of these services, they are generally delivered from a small number of centralized datacenters and consumed at some relatively large number of remote offices.

That is where things get interesting.

If we lived in a world where email and simple web page delivery was the state of the art, well, I wouldn’t have anything to write about, but we don’t.  The mainstream services that are being deployed in education, government, and enterprise accounts are ushering in a completely new level of performance requirements on the networks they depend upon.  Voice over IP (VoIP), video conferencing, IP based storage systems for file sharing, backup, and disaster recovery, and recently the deployment of virtual desktop services all bring with them new performance requirements.  Yes, that means more bandwidth, but that is just the tip of the iceberg.  All of these applications also have very real requirements on critical network parameters such as (packet) loss, end to end latency, and jitter.   Unlike simple transaction and messaging applications like HTTP delivery and email, when these new “performance sensitive” applications run into in appropriate loss, latency, and jitter, the result is application failure.  Dropped calls and video sessions.  Failed storage services including backup and recovery, and “blue-screens” where virtual desktop sessions belong.  What causes seemingly healthy networks to suffer from latency, loss, and jitter issues?  More on that in a later blog……

Successful cloud service delivery to remote sites is dependent on managing performance at that remote site.  Not datacenter application performance, or server performance, or network device performance.  Service level performance analysis from a remote site is a new topic, and we call it Remote Performance Management or RPM.

Let’s start with the basics, what do we know about RPM.

First, RPM is a location dependent topic.  Of course, the traditional datacenter performance management issues need to be dealt with.  That is part of datacenter service delivery 101.  No debate.  But if we care about the service quality that the users are experiencing, then we need to understand performance from the perspective of the end user, at the remote site.

Next, we need to address the complete performance management lifecycle.  Simply put, Assess the remote office performance PRIOR to service deployment; Monitor the remote office performance DURING service operations, Troubleshoot issues QUICKLY (like you’re there), and Report on the good, the bad, and the ugly.  When you add it all up, you need a broad set of capabilities to meet these needs

Finally, we need to keep it simple, affordable, and scalable.  The problem with most solutions around the remote office is not the device cost, but rather the administrative cost.

The bottom line is that if you are attempting to deliver today’s critical services for remote site consumption, you need to understand performance, so you’d better check your RPMs…….

PathView customer Derek Abrams, a Certified Videoconferencing Engineer and Operating Systems/Network Analyst at Oregon State University has faced some challenges specifically related to network management within a university environment.

Abrams has shared his story with us in an article that discusses how the complex, widespread network system within a university network functions similarly to a cloud network with multiple, independent service providers. This leads to inconsistent and unreliable IT services and network performance.

Read more about why Abrams and his team chose PathView to address these issues and improve network management at Oregon State.

Interested in trying PathView on your own network? Sign up for a free PathView trial here.

Follow us on Twitter!

Error: Twitter did not respond. Please wait a few minutes and refresh this page.

%d bloggers like this: