Filed under: Performance Monitoring
By Cliff Chapman, Application Delivery Architect, LinkStatus
Was Shakespeare’s Rosalind in a Telco’s QoS presentation when she inquired “Why then, can one desire too much of a good thing?” She was hooked. QoS would solve all her Application performance problems. “I’ll just need Expedited Forwarding for voice and video, something middling for Thin Client and I’ll let the rest rot in hell” (English for best efforts), she demurred.
Rosalind was admired for her intelligence so her next phone call (within obvious 16th century bounds) was obvious – she needed a tool to independently verify that QoS was properly implemented by the Telco.
Whiz forward 400 years. The great thing about QoS from the Telco’s view is that normal people (customers) find it difficult, if not impossible, to contradict Telcos assertions that “it’s all working properly” as there are very few tools around to help. Notice I said “very few”, but not none.
I’ve found most people simply don’t look beyond the general promise that QoS will fix everything. Voice not working? – “But I’ve got QoS” they say. Citrix keeps hanging? “BIG QoS” they say. In most cases, QoS problems can be almost impossible to diagnose. Even Wireshark might only tell you what actually is happening, not what should be happening. With OoS it is critical to be able to actively test the end to end performance characteristics of multiple QoS classes at the same time.
1) Voice quality is mostly poor, even with a single call. PathView Cloud’s layer 3 diagnostics show me that a router 2 hops from the source has re-tagged the packet with default DSCP, effectively switching off QoS for Voice from that router onwards.
2) QoS size has been specified to run 10 concurrent calls but with any more than 5 concurrent calls the quality of all conversations is degraded. PathView’s AppView Voice module ramps up from 1 to 10 calls, and I see MOS degrading after 5 calls -the diagnostics show me increasing packet loss above 5 calls and the problematic router. Conventional PathView Cloud tests the available bandwidth at QoS EF and I can clearly see it is half of what I expect and the bottleneck is at the same router.
On small bandwidth links I sometimes run AppView Voice simply as means of flooding the link with traffic of a set QoS value. Then test how well the infrastructure’s QoS mechanism is protecting higher priority traffic using the normal PathView features. Wouldn’t it be nice if I could flood bigger links using PathView Cloud? Well, my fingers are crossed.
When QoS is correctly set up it is a good thing, and yes, my dear Rosalind, you can have too much if you don’t deploy tools to ensure it stays set up and aligned with the needs of the business. I don’t know of a better tool, at any price, than PathView Cloud for comprehensively testing the operational effectiveness of QoS schemes.
It never fails to bring a smile when customers say “I told the Telco where and what the problem was and they said – ‘How did you know that’?” And that happens often. Thanks PathView Cloud!