Contentious? Semantics? I don't think so. If reactive means taking action after an event it's just optimistic nonsense to use proactive in the sense of taking action before an event. What about predictive? Sounds a bit like standing in your data centre waiting for your twig to twitch or something from the Kaiser Chiefs.  Maybe anticipate? Expecting and planing for (but not stopping) potential future events? How does that help?

Surely what we call proactive just means plain old reactive, but reacting in response to indicative signs giving high confidence that "By the pricking of my thumbs, something wicked this way comes".

If we want advance warning of something undesirable we have to accept the best we can achieve is to get low intensity signs that unambiguously foretell the coming storm. 

From a network infrastructure perspective, these warning signs are increases in latency, round trip time, packet loss and a whole heap of identifiable permanent or transient media issues. Chicken and egg often links these to reduced available bandwidth caused either by increased utilisation or reduced total bandwidth due to incorrect QOS configs, contended lines or any manner of plausibly deniable Telco statements.

For 'apparently' proactive management of network performance take a look at PathView from AppNeta. You'll get advance warning signs for every conceivable network condition and automatically triggered diagnostics to pinpoint what went wrong and how to avoid it in the future.

So if you're still convinced you can be truly proactive go for the lottery or the horses. If you're a pragmatic reactive go for pathview.

Cheers, Cliff.

Slow networks. Some people wonder if there's any other type, often because they simply can't confidently verify the problem is, or is not, the network. Here's a great solution that couldn't involve less risk or pain to try.

With 10 years of impeccable credentials in the US, AppNeta's PathView Cloud hit the UK just last year. It continuously monitors all the vital signs of your network infrastructure (see below) by invisibly exercising it and experiencing the same conditions as your applications. But, where applications and users just groan and get slower, PathView's reaction to declining conditions is to roll up it's sleeves and get stuck in with deep diagnostics to pinpoint where and what's happened.

It's described as having "instant value" and in my experience that's entirely accurate. A small download, a 2 minute installation and you're away monitoring and diagnosing to your hearts content. Many evaluations have accurately diagnosed long-standing network problems within minutes. If a download is not for you try a free evaluation using the microAppliance below.

Call me, Cliff Chapman, on 023 9265 8344 or 07887 506009 or email cliff.chapman@linkstatus.co.uk and see how PathView Cloud will help you or your customers solve network performance problems.

You need to know the smallest capacity bandwidth in the direction of the server to the client and the shortest round trip time for the end to end path between them. Ping is good enough for RTT but measuring bandwidth could be tricky. Failing all else you'll have to trust your telco contract (the better answer comes later). These will help you estimate the best possible performance that network path will support. Be warned - Best Possible Performance will never be achieved in reality.

How to (very) roughly estimate BPP for free? Run the application on a LAN. Download a free copy of wireshark and follow instructions to get a packet capture that contains an example transaction of your new app.  Don't worry what else is captured, we'll filter that out next. From the 'Statistics' menu, select Conversation List > TCP. 

You'll get a pop up screen showing all the conversations that have been captured (so make sure your not also browsing any web sites you wouldn't want your mum to see). Highlight the one you want by identifying the app server address and make a note of the number of packets and bytes transferred in the server-to-client direction. 

Now you know these things. For the network path; bandwidth and minimum round trip time. For the application; how many bytes were transferred and how many packets it took to transfer them. Oh, and remember I said this would be a rough estimate.

Let's say bandwidth is 1M, minimum RTT is 100 milliseconds, the transferred volume is 500Kbytes and the number of packets is 400.

Ignoring overheads a 1M line can transfer 125Kbytes per second so 500Kbytes would take 4 seconds. But RTT is 100 msecs and it is encountered 400 times. This adds 40 seconds to the overall transaction time giving 44 seconds in all. Let's compare that with a LAN.

The transfer rate of a 100M LAN is 12.5Mbytes per second so the raw transfer is 100 x faster at 40 milliseconds. Let's assume LAN RTT is 100 microseconds. 400 round trips therefore adds 40 milliseconds extra delay. Total transaction time is 80 milliseconds.

Now picture yourself thinking "what if I try more bandwidth?". Here's why that doesn't work. Lets say you take your bandwidth 1M to 100M but cannot improve RTT. The raw data transfer reduces from 4 seconds to 40 milliseconds but we still have to add 400 round trips at 100 milliseconds - which is still 40 seconds. The 100M upgrade has just improved the performance from 44 seconds right down to 40.04 seconds!

Also remember that we've just estimated the BPP and that will never be achieved. There will always be other apps on the network consuming bandwidth leaving less for your new app. As bandwidth is consumed the RTT gets worse and you may have packet loss and other such nastiness on your network.

A better way to assess the likely performance of a new app is by

1) Using PathView Cloud to continuously monitor the network paths over which the application is to be run to get realistic values for available bandwidth (i.e the difference between total bandwidth and utilisation) and the RTT. This will also expose previously hidden network problems that will further erode performance.

2) Use those values to set up a WAN emulator, through which you operate the application on a LAN.

You will then directly experience application performance as if you were working from that branch. Testing in this way also allows you to evaluate possible fixes where the performance is unacceptable. Bandwidth and RTT parameters can be adjusted to discover what type of WAN technology is most suitable or WAN optimisation can be tested directly across the emulated WAN so you can see the degree to which performance can be improved. All in the comfort of your own office.

If you have a little bit of money and don't have all the time in the world we can do all this for you. Our Application Readiness service will deploy PathView to gather vital network stats, then bring WAN emulation to your site so that you can experience the branch's eye view of application performance. We can advise about different optimisation techniques that could improve performance and we can actually deploy optimisation in the emulated environment so before and after improvements can be experienced.

The Application Readiness testing is normally performed in a single day. We bring everything required to you. You just supply a workstation and an operator familiar with the application to be tested. Drop me a line if you're interested in understanding how your new app will work over the WAN before finding out the hard (and expensive) way.

Cheers, Cliff.

Our Cloudsmart service is the fastest and most affordable way to fix existing network problems and keep your network fit and healthy. It includes an initial baselining assessment of network health and performance, ongoing continuous performance monitoring, monthly performance reporting and proactive troubleshooting. See the press release.

Today’s leading applications are becoming increasingly performance sensitive. Performance-reliant applications such as VoIP / UC, IP Storage (back-up and disaster recovery), Collaboration, Application & Desktop Virtualization, and SaaS / Cloud services are highly dependent on specific performance parameters such as capacity, latency, jitter and loss.

Organizations often underestimate the task of network assurance prior to deploying a performance sensitive application such as VoIP, VDI, video conferencing to remote locations. Often, this is because the task seems too difficult to perform within constraints of time, resource and budget. The Cloudsmart service, based around the PathView Cloud suite lets you accurately measure how reliable your network will be. It is quick and easy to deploy and includes clear reports that show the condition of the network and actionable recommendations for improvement

PathView Cloud provides businesses with an inexpensive, easy to use means for continuously measuring performance parameters without impacting end user experience. When a problem is detected, PathView Cloud automatically tests each hop in the application delivery path to pinpoint the issue. A mature knowledge base provides detailed information about any highlighted issue, its potential affect on application performance and how to fix it.

Join our mailing list to get your free information pack showing how to keep your entire network tuned for performance. Joining the mailing list is also the first step to free registration for our remote packet capture service.

Sign up for our Email Newsletter

How would you like to visualize the performance of your entire network from one screen? That's LAN and WAN - Gigabit to skinny. I really mean performance not just availability or whether a device is responding. PathView Cloud can group, sort and present a live matrix of network path performance, colour coded to show compliance with user-defined thresholds of Capacity, Utilisation, Data Loss, Latency, Jitter and many more essential path characteristics.

Watch a little Prezi about it and use the 'More' > Full Screen option so you can zoom in on the screenshots.

I'll follow up soon with another Prezi for Path Diagnostics.

Go easy on me, I'm new to blogging! Hope you enjoy...

Cheers, Cliff.