(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. :) 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. :) 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
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. :)
Admit it your a troll at heart ;)
*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
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. :) 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
*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
At 06:27 PM 3/21/2003 -0500, alex@yuriev.com 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?
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
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
is a 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.
...
etc etc etc
Alex
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
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. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Fri, Mar 21, 2003 at 04:58:44PM -0500, Deepak Jain wrote: [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
On Mon, 24 Mar 2003, Joe Provo wrote: > Peering within [your own service area] 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. 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. :-) -Bill
participants (7)
-
alex＠yuriev.com -
Bill Woodcock -
Deepak Jain -
Joe Provo -
Leo Bicknell -
Stephen J. Wilcox -
William B. Norton