Home page logo
/

nanog logo nanog mailing list archives

RE: QOS or more bandwidth
From: "Kavi, Prabhu" <prabhu_kavi () tenornetworks com>
Date: Tue, 29 May 2001 13:40:58 -0400


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:  prabhu_kavi () tenornetworks com
100 Nagog Park                  WWW:    www.tenornetworks.com
Acton, MA 01720



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




  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]