(possible Flame bait) Backbone Building vs Transit purchasing

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

Over the years, as economics have moved around and such, the question of
whether its *profitable* to build a backbone and peer-off most or all
traffic vs buying transit for all or some destinations has moved around.
Some of the factors are economic, some have to do with onerous or
non-existant peering possibilities with one or more networks.

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

I was in a discussion about this fairly recently, and I can imagine a number
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. :slight_smile: If you want to
shoot out numbers (privately) I am fine with that. Let's start the bidding
at 1Gb/s sustained. :slight_smile:

Deepak Jain
AiNET

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

Admit it your a troll at heart :wink:

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

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

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

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.

[skip]

You are forgetting:

salaries
depreciation
leases
IRU
financing expenses
...

etc etc etc

Alex

> > *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:
http://arneill-py.sacramento.ca.us/ipv6mh/ABusinessCaseforISPPeering1.2.pdf

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

http://www.deliandmarshall.com/docs/ATM-based.pdf

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.

[skip]

You are forgetting:

salaries
depreciation
leases
IRU
financing expenses

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.

In a message written on Fri, Mar 21, 2003 at 04:58:44PM -0500, Deepak Jain wrote:

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

This is very much a moving target as various items (circuits, ports,
ip bandwidth) get priced at rates well above over below cost
depending on who has how many of them. That said, in the long
term, for anyone of size (which I'll define a a few gigs of traffic)
I don't think there is a significant economic difference between
the two options. This is assuming each option is executed well,
with good planning and financial sense. One will be cheaper than
the other from time to time, but there will be no clear winner.

This means it comes back to a more basic business decision, do you
want to be an ISP? Even if the costs are the same for either option
a company may be better off just buying bandwidth because building
a network is not at the core. On the other side, you might be
trying to sell to people who require you to have a network to be
taken seriously. At the end of the day my assumption that both
options are executed well is the most often violated, and a prime
cause is that it was not in a companies core interest.

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.

I think we are talking about two different things. I am aware of at least
several networks pushing closed to 1Gbit/sec which has no one on staff that
understands routing at a level greater than putting a neighbor section in a
cisco config. Neither do they have understanding of diverse paths,
geographic restrictions and so on. However, none of those issues creates
problems since they are purchasing transit from providers located in a
single place and sell it to the customers that take delivery of the IP on
their terms. Should they want to move to a peering model, they would
suddenly need to pay for people who know, understand and can deal with the
operational issues that peering presents.

Alex

[snip]

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

I was in a discussion about this fairly recently, and I can imagine a
number of people have started asking the same questions.

Some of us have done and continue to do such large-scale operational/
financial analysis on a recurring basis. The analysis is wildly different
for different networks. If you have services offered in $large_footprint,
there are compelling reasons to stitch all the service islands together
[if you have trouble with this, ask any LEC, multi-market MSO, etc].

Peering withing $large_footprint should be considered a no-brainer.
Building outside your footprint is always an interesting question;
even if you have at least one major peering point within your footprint,
you may need to visit one or two others outside your footprint to meet
'site diversity' and multi-point requirements.

In a nutshell, peering is as useful as you make it a stretegic part of
your business plan. Which means simplified equations for the cost/benefit
analysis will almost always be wrong. Given your second reductive
statement ignoring differing quality levels or potential peers and
service providers, I don't think it is worth delving deeper. Bluntly,
there is no commodity apples-to-apples value to 'transit'. The circuit-
switched bean counters may not yet see the different between long
distance voice providers and IP transit providers, but I would expect
more from this community.

Cheers,

Joe

Which are, just to reinforce what I believe to be Joe's point, _their_
business requirements, rather than _your_ business requirements, and thus
should be considered more in the light of competitors attempting to
compel uneconomic behavior in one, in order to reduce one's competitive
advantage relative to themselves.

Looking at this thread overall, one has to either work from the assumption
that everyone's free to make this choice (that is, that a possible outcome
is that there could be a situation in which everyone was free to buy
transit somewhere, and thus free of the requirement of having a downstream
or peer connection to the entire net), or the assumption that the
existence of this choice as a possibility is dependent upon some people
not making that choice ("Tier 1s") so that other people can choose to buy
transit from them, or from their customers, or whatever.

The former notion is certainly an interesting one to puzzle through the
consequences of. :slight_smile:

                                -Bill