Alternative to NetFlow for Measuring Traffic flows

Tue Dec 17 19:25:58 UTC 2002

On Mon, Dec 16, 2002 at 10:53:26PM -0800, William B. Norton wrote:
> 
> Right, it is crude, but in an economy where business decisions
> require "Quantifiable *Proof*", this is quantifiable and easy to
> do. Some Peering Coordinators are  putting together business
> plans now for peering at the IX that includes the #'s of Mbps of
> peering traffic, and e-mail confirmation from the peers at the
> IX that they will indeed peer with them at the IX.  Smart customers;
> if they exceed the breakeven point then peering makes sense. A
> lot more work up front than it used to be.

Business decisions surrounding bandwidth and connectivity is still
in the early years of development.  A few, highly technical people
understand it.  Unfortunately, most of those people do not also
know how financial roi works, or how to define a project or strategy
that meets business hurdle rates.

I personally feel that this is a gap in how internet marketing
started idetifying measurements such as `click-throughs' and
application- oriented numbers to fulfill their statistical needs
for building partners and identifying their relationship to their
market.  Clearly, just by looking at the names they chose for things
(`click-throughs'?), they had no idea what they were doing, and
likely were also not willing to listen to their technical counterparts.
Engineers don't know anything about business partnerships and
relationships to their market, right?

As a business unit manager responsible for Internet connectivity,
one is obligated to look at their WACC / discount-/hurdle- rates
and determine the value of future returns.  Find out the WACC and
marginal tax rates of your company.  Find a financial controller,
or someone who manages finance and locate information on how capital
expenditures are evaluated and depreciated (how long?).  Find out
what metrics they want and need for technology expenditures that
involve both capex and opex in the same budget/project.  What are
the business expectations?

> Another approach I have been thinking about is to generate "Peering
> Profiles" for the community...here is how it works. Let's say I
> work with a few Internet Gaming companies and find that the
> netflow stats show a certain pattern, or profile of traffic
> destinations. Maybe I find that
> 2% to Cox
> 3% to Shaw
> 2% to Comcast
> 5% to Roadrunner
> 2% to Adelphia
> and the next top 20 ASes represent the next 10% of traffic.
> 
> Anonymized, this "Peering Profile" for Internet Gaming companies
> can probably be applied to other Internet Gaming companies and
> can provide a rough idea of good targets for peering and how much
> traffic can be expected at a peering point, as a percentage of
> their total traffic. Empirically, these top traffic destinations
> and volumes have been large enough, 10's of Mbps each, generally
> more than enough to justify peering a an IX where the breakeven
> point is 10-30Mbps. The design of the tool/template is pretty
> obvious from there.

Bill, I fully agree with your methods and think they are wonderful.
If there is any quantifiable proof, it needs to be identified and
executed on.  Get some numbers, any numbers.  Take some tcpdump
samples, or even load a permit acl on your routers to determine
estimates.  What is the problem you are trying to solve?  My answer:
an internal business unit agreement that a minimum percentage of
costs can be reduced through peering.  Do this in any way that you
can.

Why is this so difficult?  Probably because the disagreeable parties
aren't talking the same language.  I also feel that in many
businesses, technology (such as bandwidth) is not taken seriously.
Prothat include capex+opex to a variety of vendors (creating vendor
dependence) with new "extra" routers (equipment), and seemingly
costly exchange point "extra" connectivity, with "extra" racks and
power requirements with monthly re-occurring charges - well that's
just not intuitively cost-effective, now is it?

Ask the right questions.  If managers do not want to do peering
because it doesn't meet some marketing or partnership requirement,
then take some different angles.  If managers don't believe that
peering can actually save money, come up with the numbers and the
financial language they are used to.

If you are told not to come up with technology estimates, or simply
can't because you don't have the time - then consider using someone
else's work and time (like Bill Norton).  Augment/replace estimates
(and even really accurate NetFlow data) with externally researched
estimates and national or global averages.

BTW: Yes, I believe NetFlow is an excellent tool, and I use it
myself for determing who would make a good peer (and ras is correct
that using an external routing table along with the netflow data
improves this even further).  NetFlow is easy.  Set it up and use
it, or get the needed help from your vendor.  If you determine that
for your environment - that NetFlow is not easy, then use something
else.

dre