If you also add the cost of buying a decent CPU based device that can perform complex QOS in comparison to say a decent gigabit switch, those numbers will add up even faster. -----Original Message----- From: jamie baddeley [mailto:jamie.baddeley(a)vpc.co.nz] Sent: Sunday, 29 March 2009 8:37 p.m. To: David Robb Cc: nznog Subject: Re: [nznog] QoS-IXPs On Sun, 2009-03-29 at 09:00 +1300, David Robb wrote:
On Sat, 28 Mar 2009, Brian E Carpenter wrote:
Matthew,
I said earlier that I prefer there to be enough bandwidth. But when there isn't?
When there isn't enough bandwidth then QoS is a temporary solution. The answer is to get more bandwidth. Otherwise you're making the choice between delaying or dropping lower class traffic, and eventually[1] that'll impact on the performance of that class sufficiently that those using it will give up.
For short term problems eg abnormal traffic flows causing congestion, sure. For long term traffic management - get bigger tubes.
That's right. If it's a tossup between the costs of engineering time to develop (and sustain(!)) a plan for QoS in those times of need versus a more conservative position around standing up a bigger tube, I'd go for a bigger tube everytime. Consider this. Lets your current guideline is 70% average load plus some QoS for the unexpected events, and after that you order a bigger pipe. Quantify the cost of developing a decent QoS plan to deal with those events. I'd assert that's a significant amount of time. And in today's environment where resources of those sorts of skills are short, that's fairly significant. Compare that to say taking a position where it's 50% of average load triggers that a decision to make the tubes bigger. Let's say that decision means you order bigger tubes 12 months earlier than the 70%+QoS plan. Is the collective incremental opex spend on a bigger tube for those 12 months greater than the capital you would have invested in developing the QoS plan? I'd assert that it is not. Really this sort of thing is an argument between two schools of thought. The School of Brute Force vs The School of Bandwidth Scarcity. I know which side I am on. But that's just me. Finally, an IX architecture comparative to the networks that connect to it is simple. I suspect that if the networks connecting to it are able to get over any Service Level Commitments to their customers, such that the IX is the bottleneck, like others have said, choose another IX. jamie _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog