State your opinion on below article Mr QoS versus Mr Bandwidth

Mr. QOS vs. Mr. Bandwidth By Sandra Borthick | Sep 01, 2005 By now, we all know that more bandwidth is better, and many believe that having enough bandwidth eliminates the need to do anything special for voice, video or other delay- and losssensitive traffic. In other words, if you have enough bandwidth, these flows dont need quality of service (QOS) mechanisms to protect or guarantee their performance. Other folks arent so sureand I confess I am one of them. A recent email exchange I facilitated between two of BCRs contributors still has me scratching my head. Lets call them Mr. Bandwidth and Mr. QOS. It all started when Mr. Bandwidth told me VOIP traffic runs just fine on the Internetas long as you have plenty of bandwidth. I pushed back (as editors are wont to do) because I thought that, even if you have unlimited bandwidth, you still need to either separate UDP traffic (voice and video) from TCP (most data) or otherwise do QOS in order to keep UDP from overrunning TCP, because UDP has no flow control. I emailed Mr. QOS, asking who was rightMr. B or I. Mr. QOS surprised me by saying Mr. B was rightas long as there really is plenty of bandwidth end to endincluding the access lines and that nasty shared WiFi network if the user happens to be on one. Generally speaking, wrote Mr. QOS, you will be OK if you can keep all of the hops under 25 percent aggregate (data and voice) utilization. Mr. Q went on to explain that the real problem comes down to ensuring that VOIP calls are not disrupted by other traffic on the access line. Mess up a minute or even 10 seconds and the VOIP call gets real bad, real fast, he wrote. This does not typically occur in the backbone of any serious ISP, he added. They are operating at 1 to 5 percent utilization, and even a bunch of FTP downloads does not move the meter much towards 25 percent. But if there is a cool Grateful Dead giveaway one day, then those music or video downloads will do big damage to any voice calls. Video is even more sensitive. Lies, LiesAnd QOS? I sent Mr. QOSs comments to Mr. Bandwidth, who fired right back with his response. Who are you talking tosome academic? There are lies, lies and statistics, he wrote. I have looked at, worked with and played around with this utilization stuff for many years. People with real, practical first-hand experience will tell you that Mr. Qs 25 percent number is way too low. Link utilization can easily run to 80 percent or more on high-speed links, without perceptibly impacting traffic. According to Mr. B, a better way to look at these numbers is to consider that a link utilization of 40 percent means that it is idle for 60 percent of the measurement interval. There is nothing in the queue over half the time, and the link isnt adding any delays to any traffic, he explained. But traffic rarely, if ever, arrives all at once. Yes, there can be occasional bottlenecks, not only in the network, but usually with server capacity. Traffic is usually spread out over the utilization measurement interval with plenty of gaps for new packet arrivals to go unimpeded. Then Mr. B sounded the note I thought would end the discussion agreeably: QOS is never a substitute for having enough capacity. But I was wrong; Mr. QOS wasnt finished making his casehis two cases, in fact. Mr. Qs first case shows how 40 percent utilization is a good number for backbones, where QOS really is unnecessary. He calls it The Case of the 10-Gbps (Metro Gig E or SONET OC-192) Trunk Line. For a very tight measurement period of one second, the link is idle to take on more traffic 60 percent of the time, he wrote. This translates to being able to consume 6 Gigabits in that second. Now let us assume that the users passing their traffic over this particular link are doing their typical Internet thing, Mr. Q continued, and let us assume that all the additional users are downloading some heavy stuff (music, videos, shareware or porn). All of these downloads will run at about 0.5 Mbps. Why? Because all of it will be limited by the TCP window, by the server not wanting one user to hog the service, by RTT limits, etc. But lets say that you are really hot and know how to make a single file transfer, or video stream run at 1 Mbps, he speculated. OK, we can take on 6,000 such hot flows of traffic in that one second. But how likely is that to occur? Not likely, so case closed: Looks like 40 percent utilization is a good number in the core, and no one needs QOS. Dont We Need QOS At The Edge? It is on the access links, however, where Mr. Q sees the need for QOS, as his second case demonstrates. Its called The Case of the Cable Modem Broadband Access Line. On a good day, my cable modem access runs at about 3 Mbps downstream and 0.5 Mbps upstream, he wrote. Lets assume, for the sake of comparison, that others in my neighborhood are already consuming 60 percent of this capacity. This isnt an unreasonable assumption in the evening, when many people are using the Net, but it means I am left with 1,200 kbps downstream and 200 kbps upstream. Now, say that I am trying to run a Skype call with my friend, Mr. Q continued. However, my daughter just turned on an interactive game or, more likely, my wife just shut down her PC, which launches a procedure to back up changed files over the Internet. Either one of these events consumes more than 200 kbps on the upstream. On my Skype call, I can still hear my friend but he can no longer hear me. Mr. Q said this exact scenario has occurred at his house more than once in the past month, and that QOS would have solved the problem, by keeping the Skype call running and slowing the wifes automatic backup. She is already asleep and doesnt care, he added, but this 'little nontypical problem lasts for about 10 minutes. Very aggravating. The bottom line on the access link, according to Mr. Q, is that 60 percent utilization is too high and QOS is necessary. In fact, he wrote, we need QOS at much lower utilizations. It is not worth gambling that some other big application wont consume too much bandwidthlets just turn on QOS all the time on this access line. Mr. QOS calculates that a typical flow rate of 0.5 Mbps has a 10 percent or more effect on any line that is operating at 5 Mbps, and a 20 percent effect on a line running at 2.5 Mbps. But how many access services can give you 2.5 Mbps sustained in both directions? he asks. Hardly any. The bottom line is that we need QOS on the edge and not in the core. Sounds reasonableQOS at the edge, not in the coreand again I thought the discussion was over. But Mr. Bandwidth wanted the last word. All You Need Is Bandwidth Sorry, I dont buy any of this, wrote Mr. B. Anyone can load up their lines and cause themselves a capacity problem, but why would they do that? Make the call earlier, reschedule the backup, get more bandwidth. Mr. QOS is offering the usual QOS religion, he continued, with the usual ployresorting to a long drawn out unlikely-to-occur scenario that includes the convergence of multiple worst-case events. Mr. Bandwidth then turned the tables. What happens when all the traffic is important? he wrote. That doesnt occur very oftenbut it could happen! In fact, users will always want their traffic to be the most important. Superficially, it looks like there can be no QOS in such a situation, but the correct conclusion is: There is no substitute for capacity. If QOS really did something useful, he continued, like providing end user value, then the economics would have forced it into widespread use by now. The simple fact that the Internet has become so valuable, so useful and so important to so many people without QOS proves my point. Broadband to the end user further erodes any (if there ever was one) business case for QOS, he added. Speed will kill the QOS business case at the edge, just as it did in the core. Compared to the low cost of adding more bandwidth capacity, Mr. B sees nothing but expensive downsides for QOS, which he claims the QOS religionists completely ignore. The drawbacks include the need for state management; the interpretation of what or who is important by everyone along the network path (this issue alone is major open research); huge increases in network complexity; ongoing equipment and software configuration challenges (including people with the skills to do it properly); decreased network reliability; increased capex and opex cost; complex scaling issues; increased difficulty diagnosing problemsthe list goes on and on. Those of us in the real world know QOS is bogus, concluded Mr. B, but I wasnt surprised to hear from Mr. Q. Sell QOSPeople Will Buy It I think that Mr. B is creating a big complicated specter of fear and expense about QOS, wrote Mr. Q. When I say at the edge, I mean edge: I just want my little home router to deal with QOS like I set it up. Theres no confusion about what class of traffic is more important in my house. Then, all Mr. Q says he needs is a way for my router to tell the carriers edge router on the link coming to me to do exactly the same in my direction. So, yes, there would be a bit more expense on the edge router supplied to the carrierbut it would be a small expense, and they could sell this as a feature. Carriers keep crying about being in the cut-throat commodity business of pure bandwidth, but at $5 per month, this could be a high-margin strategy. More bandwidth and user control at the edge? Maybe thats a winning combination for both carriers and customers. Sandra L. Borthick is the senior editor of Business Communications Review.