QOS or more bandwidth

Kavi, Prabhu prabhu_kavi at tenornetworks.com
Tue May 29 17:40:58 UTC 2001

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 Kavi                     Phone:  1-978-264-4900 x125 
Director, Adv. Prod. Planning   Fax:    1-978-264-0671
Tenor Networks                  Email:  prabhu_kavi at tenornetworks.com
100 Nagog Park                  WWW:    www.tenornetworks.com
Acton, MA 01720

> -----Original Message-----
> From: RJ Atkinson [mailto:rja at inet.org]
> Sent: Tuesday, May 29, 2001 1:22 PM
> To: nanog at merit.edu
> 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
> rja at inet.org

More information about the NANOG mailing list