On Mon, Dec 16, 2002 at 10:53:26PM -0800, William B. Norton wrote:
Right, it is crude, but in an economy where business decisions require "Quantifiable *Proof*", this is quantifiable and easy to do. Some Peering Coordinators are putting together business plans now for peering at the IX that includes the #'s of Mbps of peering traffic, and e-mail confirmation from the peers at the IX that they will indeed peer with them at the IX. Smart customers; if they exceed the breakeven point then peering makes sense. A lot more work up front than it used to be.
Business decisions surrounding bandwidth and connectivity is still in the early years of development. A few, highly technical people understand it. Unfortunately, most of those people do not also know how financial roi works, or how to define a project or strategy that meets business hurdle rates. I personally feel that this is a gap in how internet marketing started idetifying measurements such as `click-throughs' and application- oriented numbers to fulfill their statistical needs for building partners and identifying their relationship to their market. Clearly, just by looking at the names they chose for things (`click-throughs'?), they had no idea what they were doing, and likely were also not willing to listen to their technical counterparts. Engineers don't know anything about business partnerships and relationships to their market, right? As a business unit manager responsible for Internet connectivity, one is obligated to look at their WACC / discount-/hurdle- rates and determine the value of future returns. Find out the WACC and marginal tax rates of your company. Find a financial controller, or someone who manages finance and locate information on how capital expenditures are evaluated and depreciated (how long?). Find out what metrics they want and need for technology expenditures that involve both capex and opex in the same budget/project. What are the business expectations?
Another approach I have been thinking about is to generate "Peering Profiles" for the community...here is how it works. Let's say I work with a few Internet Gaming companies and find that the netflow stats show a certain pattern, or profile of traffic destinations. Maybe I find that 2% to Cox 3% to Shaw 2% to Comcast 5% to Roadrunner 2% to Adelphia and the next top 20 ASes represent the next 10% of traffic.
Anonymized, this "Peering Profile" for Internet Gaming companies can probably be applied to other Internet Gaming companies and can provide a rough idea of good targets for peering and how much traffic can be expected at a peering point, as a percentage of their total traffic. Empirically, these top traffic destinations and volumes have been large enough, 10's of Mbps each, generally more than enough to justify peering a an IX where the breakeven point is 10-30Mbps. The design of the tool/template is pretty obvious from there.
Bill, I fully agree with your methods and think they are wonderful. If there is any quantifiable proof, it needs to be identified and executed on. Get some numbers, any numbers. Take some tcpdump samples, or even load a permit acl on your routers to determine estimates. What is the problem you are trying to solve? My answer: an internal business unit agreement that a minimum percentage of costs can be reduced through peering. Do this in any way that you can. Why is this so difficult? Probably because the disagreeable parties aren't talking the same language. I also feel that in many businesses, technology (such as bandwidth) is not taken seriously. Prothat include capex+opex to a variety of vendors (creating vendor dependence) with new "extra" routers (equipment), and seemingly costly exchange point "extra" connectivity, with "extra" racks and power requirements with monthly re-occurring charges - well that's just not intuitively cost-effective, now is it? Ask the right questions. If managers do not want to do peering because it doesn't meet some marketing or partnership requirement, then take some different angles. If managers don't believe that peering can actually save money, come up with the numbers and the financial language they are used to. If you are told not to come up with technology estimates, or simply can't because you don't have the time - then consider using someone else's work and time (like Bill Norton). Augment/replace estimates (and even really accurate NetFlow data) with externally researched estimates and national or global averages. BTW: Yes, I believe NetFlow is an excellent tool, and I use it myself for determing who would make a good peer (and ras is correct that using an external routing table along with the netflow data improves this even further). NetFlow is easy. Set it up and use it, or get the needed help from your vendor. If you determine that for your environment - that NetFlow is not easy, then use something else. dre