Jitter and FUD
In a conversation with a co-worker Pete http://pete.kruckenberg.com/blog/ yesterday, I heard about a program, called Iperf http://dast.nlanr.net/Projects/Iperf/ . The interesting thing about the program is that it measures jitter. Since we do a lot of video here at UEN, we talk a lot about jitter. The reason we are getting tiling and ugly to look at phenomena on the student’s video is because of jitter. We speculate about the jitter characteristics of various types of transport. 802.11a (Wi-Fi) is especially suspect. We trust TDMA circuits because they seem less like to have jitter.
The interesting thing about Iperf is that it actually measures jitter. To be precise, it measures “delay jitter and loss for constant bandwidth UDP streams.” This measurement is made by filling the network with test traffic and measuring what arrives on the other end. This made me start thinking about FUD. Probably more money has been made selling FUD than has been made selling computers. Gene Amdal is credited with the term after he left IBM to found his own company. Since he was planning to have a better and cheaper product, IBM’s response was to sell FUD. They apparently did a pretty good job. I was not aware that Amdahl is still in business, but Google says otherwise.
Problems that are real can be measured before and after the fix. For example you might have 20% of your traffic in broadcast before installing a switch and less than 1% after. Broadcast traffic is a real problem, solved by a real solution. I have never heard of a similar thing concerning jitter. Well, our jitter was 20% before we switched from Frame Relay to private line T1, but now it is under 1%. Typically with FUD there is a real symptom, and a real solution that solves the problem, but no measured relationship between the problem and the solution. The question for somebody that replaces their AS400 with a water cooled IBM mainframe is not whether it is faster, whether the “safe” choice is worth what was paid for it.
So the next phase of my search was to look at one proposed solution to jitter, QOS. I searched Google for QOS. What I found was people selling QOS, and academics studying QOS. Since real problems have real rules-of-thumb, the next step was to look on the Cisco web site for QOS rules-of-thumb. I discovered a new rule-of-thumb for searching the Cisco web site. Never use the search command on the Cisco site. Always use Google. I have the Google toolbar installed, and you can ask it either search the web or search the current site. I asked the Cisco site to look for rules-of-thumb and got 105 entries. None of them dealt even remotely with QOS. I did the Google search of Cisco and came up, number one of course, with a presentation http://www.cisco.com/networkers/nw00/pres/2300.pdf from Networkers about QOS.
The first rules-of-thumb cited is you never fragment packets to decrease delay on circuits that are T1 speed or faster. Statistics are cited that brokerages, credit card authorization and Delta Airlines lose millions of dollars due to non-responsiveness. The presentation also says that congestion is the major cause of network failure, and QOS is the solution. You can make your “mission critical” traffic arrive without delay or jitter while having your less important traffic arrive at a somewhat slower pace. I believe everything that the presentation cites. What bothers me is that there are no rules-of-thumb. I have seen QOS work. I would never try to do voice or video on a circuit slower than T1 without it. I have seen QOS work for Voice-over-IP on four parallel 56 kbps circuits.
Since there is no measurement of jitter or delay or any rule-of-thumb, I get suspicious that QOS is mainly FUD. I wonder how many real problems are solved by QOS. How could you get a company to buy all new QOS enabled routers and switches for their network if the rule-of-thumb was to only use it for voice traffic on 512 kbps or smaller circuits, and video traffic on T1 or smaller circuits?
My next search will be for any tools that can measure congestion in a running network.
10:02:39 PM 
|
