Fwd: Alternative to NetFlow for Measuring Traffic flows

Wed Dec 18 04:36:16 UTC 2002

> I have found peering to have additive value; a lot of 1-2 Mbps peering 
> sessions can save as much money for you as a single large traffic 
> peer. The more traffic, the stronger the case for peering.

Sadly, this completely ignores the cost of implementing and maintaining 
peerings.  BGP does not exactly configure itself, and current routing 
technology is somewhat frail -- if it breaks, somebody has to pick up 
the pieces; if suboptimal routing results from a peering, somebody will 
have to go and tweak things.
Since the Internet is not exactly static, these things creep up from 
time to time even after a peering is established.

An exhaustive itemization of the costs of any given peering is a of 
vital component of a cost-benefit analysis, particularly where much of 
the benefit is a reduction in monthly usage based billing costs, or a 
deferral of an upgrade of a flat rate contract, rather than installing 
new parallel connectivity to meet the demands of traffic growth.  While 
such a list will vary from organization to organization, and some 
organizations may be tricky to complete, one can consider the primitive 
case of a transition from being singly homed to a transit provider to 
bring up an initial peering.

Among the things to be considered: PA address space, BGP (and making 
sure that the routers can handle the load, and so can the people 
operating them), avoidance of accidental transit, what happens to the 
peering traffic when the peering fails from time to time (or fills up 
with growth traffic over time), NOC-to-NOC coordination, impact on 
actual and potential SLA offerings, and so on.  The immediately 
subsequent peering  may not make much of an impact on many of these 
however there are real incremental costs.  Some of these may not rise 
linearly in proportion to the number of peers (e.g. there may be a step 
change),
but rather may be a function of that number, the number of your routers 
which talk eBGP, and your overall traffic load.

I know a handful of cases where a broad peering strategy had a fairly 
clear negative impact on the bottom line even though the saving in 
transit fees was both directly measurable and large.   Anecdotes are 
not general proofs, but do underline the uncertainty in your statement: 
"a lot of ... peering sessions CAN save as much money ... as a single 
large traffic peer".  [emphasis mine]

Unfortunately, discussions here seem to focus mostly on measuring the 
reduction in transit fees.  Wouldn't it be nice if this could be 
coupled with reasonable discussion about the increase in other costs, 
and how for some networks these costs are much higher than for others?

	Sean. 