On Wed, Sep 02, 2009 at 08:39:20AM +0200, Mikael Abrahamsson wrote:
> On Tue, 1 Sep 2009, Kevin Graham wrote:
> 
> >Indeed. Capacity upgrades are best gauged by drop rates; bit-rates 
> >without this context are largely useless.
> 
> If you're dropping packets, you're already over the cliff. Our job as ISP 
> is to forward the packets our customers send to us, how is that compatible 
> with upgrading links when they're so full that you're not only buffering 
> but you're actually DROPPING packets?

By all means watch your traffic utilization and plan your upgrades in a
timely fashion, but watching for dropped packets can help reveal
unexpected issues, such as all of those routers out there that don't
actually do line rate depending on your particular traffic profile or
pattern of traffic between ports.

Personally I find the whole argument over what % of utilization should
trigger an upgrade to be little more than a giant excercise in penis
waving. People throw out all kinds of numbers, 80%, 60%, 50%, 40%, I've
even seen someone claim 25%, but in the end I find more value in a quick
reaction time to ANY unexpected event than I do in adhering to some
arbitrary rule about when to upgrade. I'd rather see someone leave their
links 80% full but have enough spare parts and a competent enough
operations staff that they can turn around an upgrade in a matter of
hours, than I would see them upgrade something unnecessarily at 40% and
then not be able to react to an unplanned issue on a different port.

And honestly, I've peered with a lot of networks who claim to do
preemptive upgrades at numbers like 40%, but I've never actually seen it 
happen. In fact, the relationship between the marketing claim of 
upgrading at x percentage and the number of weeks you have to run the 
port congested before the other side gets budgetary approval to sign the 
PO for the optics that they need to do the upgrade but don't own seems 
to be inversely proportional. :)

-- 
Richard A Steenbergen <r...@e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Reply via email to