> > *IS* there a common sense number or an equation (better) anyone has worked
> > out to figure whether building a backbone (national/international) to
> > peering points (i.e. extending an existing, operational service network) to
> > improve/add peering vs continuing to buy transit?
Take a look at the financial models in:
> If you are assuming that this is not about performance then surely this is a
> very simple thing to work out?
> Cost of transit T = cost of transit/committed Mbs
> Cost of peering P = (cost of: circuits+routers+colo+nap)/Mbs of actual traffic
Right - the comparison can get a little tricky because
1) Transit is typically charged on the 95th percentile measure of Megabits per second, vs. peering, which as you will see, is a monthly recurring, not a Mbps.
2) Transit fees vary depending on the commit rate (50Mbps, 100Mbps, etc.) and terms of the agreement (6mo, 1yr, 2yr, etc.)
while peering costs are
1) Monthly Recurring circuit, colo, port and cross connect costs
<sometimes with Non-Recurring installation charges, and cheaper if you go for a longer contract term>, and
2) Capital (Router) costs are typically allocated across a number of periods based on financial standards
In "The Business Case for Peering" I ignored capital (router costs) as they were highly variable across the different ISPs I spoke with. Everyone had a different kit.
In the "Do ATM-based Internet Exchange Points Make Sense Anymore?" white paper I spoke with more Peering Coordinators, made some assumptions based on their suggestions, and added the capital costs into the equation:
The good news is that transport prices have dropped like a rock, with cut throat competition in the metro markets. Transit has also dropped substantially, while IX fees seem to have remained about flat. You have to get your own #'s and do the math, but the above papers can give you a good start, and the transport/ transit/IX fee #'s in this last paper are pretty recent (October 2002).
> If P>T go and push your network out to the peering point it will save you money.
> Now.. at present your problem is that T is very low, and certainly lower than P
> unless you are moving quite a lot of traffic.. 1Gb is a lot of traffic, so all
> you need to do is to figure out the costs in getting to a NAP and how much
> traffic you can shift.
You are forgetting:
As for salaries, I spoke with the Peering Coordinator community about this and there was some debate about this, with some claiming that once the peering is set up, there is very little to do, so not much staff time was required to care and feed for the session. The claim was that the NOC was capable of servicing the needs of the peering session and 2nd level support was already in place if they couldn't. So the salaries were already covered in the network engineering budget.
Others claimed that Peering is a local routing optimization, and in the worst case, it fails, they turn it off, and they go back to buying transit to reach those routes.