North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

## Re: (possible Flame bait) Backbone Building vs Transit purchasing

• From: Stephen J. Wilcox
• Date: Fri Mar 21 17:54:04 2003

On Fri, 21 Mar 2003, Deepak Jain wrote:

> Notice, I didn't call this Peering vs Transit. I don't want to get into that
> discussion. :)

> *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

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

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.

A common mistake I see here tho is people calculate their peering cost as a
function of capacity, and you need to base it on real traffic, thats to say if
you plug a GigE port into an exchange at \$1000/month and then only shift 2Mb
your cost is \$500/Mb - seem obvious? Well people still keep working this out on
capacity not reality, unless you can fill that capacity quickly you need to be
realistic!

The other oversight is your transit is likely to be a fixed term based
commitment, ie you have committed 100Mb over 12 months. Offloading 50mb of that
traffic as peering in month 3 will only increase your costs as you end up paying
for unused bandwidth.

Steve

>
> of people have started asking the same questions.
>
> To be fair, and hopefully eliminate any religious issues. Let's assume 1)
> The network-in-question's traffic is balanced [1:1 push/pull] -- I know, we
> are talking theoretical here. 2) That "transit" implies a few good networks,
> with redundancy and fault-tolerance. More specifically, it is not assumed
> that "peering" or "transit" has any net-effect on the customer base because
> 1) if peering is insufficient, some transit will remain, and 2) if some
> transit provider is behaving poorly, there is another transit provider
> available to shift traffic to.
>
> I hope this is a reasonable groundwork for a discussion. :) If you want to
> shoot out numbers (privately) I am fine with that. Let's start the bidding
> at 1Gb/s sustained. :)
>
> Deepak Jain
> AiNET
>
>

• Follow-Ups:
• References: