|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: QOS or more bandwidth
There is definitely a break-point for when QoS (or even a single component of QoS like traffic engineering) makes sense. Someone asked earlier in this thread if it was cheaper to add capacity or pay for the bright engineers to make TE or QoS work. For large carriers, the right answer is often to pay for the bright engineers. I did some traffic engineering work for a major IP carrier a few years ago. The cost savings from traffic engineering at the time more than paid for the cost of the quality engineers they had. Of course, the same amount of bandwidth they had then would now cost much less, and be considered a small network, and the results today could well be different. Prabhu ---------------------------------------------------------------------- Prabhu Kavi Phone: 1-978-264-4900 x125 Director, Adv. Prod. Planning Fax: 1-978-264-0671 Tenor Networks Email: [email protected] 100 Nagog Park WWW: www.tenornetworks.com Acton, MA 01720 > -----Original Message----- > From: RJ Atkinson [mailto:[email protected]] > Sent: Tuesday, May 29, 2001 1:22 PM > To: [email protected] > Subject: RE: QOS or more bandwidth > > > > At 10:15 29/05/01, Irwin Lazar wrote: > > >FWIW, I recently heard someone ask the question - "how do > you go to your > >investors and tell them you need more money for more > bandwidth because you > >don't want to efficiently manage your existing capacity?" > > > >This is the business case for QoS, IMHO. > > Whenever I did the cost of deploying and managing fancy QoS > and compared it with the cost of getting and managing more capacity, > it was always MUCH MUCH cheaper to get and manage more capacity > than to mess with more QoS. > > Other folks mileage might vary. I'd encourage folks in > that situation to fire up a spreadsheet and do the math. The > critical variable in my cases was accounting properly for the > increased ongoing operational costs of maintaining a QoS-enabled > network. Those turned out to be quite high. > > Ran > [email protected] > >
|