Peering and Transit Cost Software: What Would That New Session Actually Save You?

Why the transit invoice and the flow data never meet

Your monitoring shows terabytes crossing ports. Your invoice shows a single number derived from the 95th percentile of five minute samples over the billing month, which is the standard convention across the transit market. Between those two facts there is no bridge, and the absence of that bridge is why capacity decisions in this industry get made on instinct.

Here is the conversation that happens every quarter. Someone in finance asks why the transit line went up. The network lead says traffic grew. Finance asks whether peering more would help. The network lead says probably, and pulls a candidate list from PeeringDB of networks present on the same exchange fabrics. That list has two hundred entries. It says nothing about how much of your billed percentile those networks actually represent, whether the traffic is inbound or outbound, whether it would even shift given your route policy, or what the port and cross connect cost would be against the saving. So the decision gets made on the reputation of the ASN rather than the arithmetic, and a year later nobody checks whether it worked.

The structural issue is that the percentile is not an average and does not behave like one. Your billed number is set by a small number of five minute intervals in the busy hour, so shifting a large volume of off peak traffic changes your bill by nothing at all, while shifting a modest volume that happens to sit inside the peak intervals changes it materially. Any analysis that reasons about monthly totals, which is what most dashboards show, is answering a different question from the one your invoice asks. Engineers know this. Almost no tooling models it.

Problem 1: you cannot name what sets the percentile

The billed number comes from perhaps a few dozen five minute samples out of the roughly eight thousand in a month. Ask which prefixes, which customers, which content sources and which directions were present in those specific intervals, and the answer requires joining flow records against a time window that nobody has isolated, and then attributing bytes to destinations that were resolved by whatever your routing table looked like at that moment.

Kentik does flow analytics genuinely well and will show you top talkers by ASN over a period. Nokia Deepfield is strong on subscriber and DDoS visibility at carrier scale. Flowmon is solid on the security and anomaly side. What none of them does out of the box is compute your specific supplier's percentile under your specific contract terms and then decompose that number into contributions you can act on, because your contract terms are not in their product.

What a custom build does: reconstruct the billing period sample by sample from your flow exports per supplier port, identify the intervals that set the percentile, then attribute those intervals down to prefix, ASN, next hop and direction. The output is a short list, usually a handful of destination networks and one or two of your own customers, that between them account for most of the number you were billed for. That list is a decision, not a dashboard. Everything else in this category is downstream of getting that one report right.

Problem 2: a peering candidate list is not a savings model

The standard analysis is a join between your top ASNs and PeeringDB presence on exchanges you already sit on. It produces a plausible looking list and a number that is almost always wrong, for three reasons everyone in the field knows and few tools handle.

First, not all of the traffic to a candidate ASN would actually move. They announce a subset of prefixes at the exchange, often from a specific region, and the rest stays on transit. Second, the traffic that moves has to move in the peak intervals to change your bill, and a candidate whose traffic is entirely evening streaming may be perfect while one whose traffic is diurnal business hours may save you nothing. Third, the saving is bounded by the shape of your commit: if you are well under a committed level, shifting traffic off transit saves you exactly nothing until the commit renegotiates.

What a custom build does: model the candidate properly. Take the prefixes that ASN actually announces at each fabric you are on, from your own route collector or a looking glass, intersect with the traffic you actually send and receive to those prefixes, restrict to the intervals that set your percentile, then apply your real contract arithmetic including commit floors, overage rates, tiered pricing and the term remaining. Add port and cross connect cost, plus the IX membership fee, and produce a payback period per candidate. Sort by that. Networks that look enormous by monthly volume routinely fall down this list, and unglamorous regional networks routinely rise. That reordering is the value.

Problem 3: flow data lies unless you join it to your own routing table

NetFlow, sFlow and IPFIX tell you a source, a destination, a byte count and an interface. They do not tell you which AS path that traffic took, which of your suppliers carried it, or whether it would have taken a different path had a peer been available. Sampled sFlow adds a further layer, since sampling rates on high speed interfaces mean small flows are statistically unreliable and anyone quoting exact numbers off a heavily sampled feed is quoting noise.

Any analysis that resolves destination ASN from a public mapping rather than from your own routing table will disagree with reality wherever your policy is doing something interesting, which is precisely where the money is. Localpref, communities you set on customer routes, selective announcements at an exchange, backup paths that only activate under failure: all of that is in your RIB and none of it is in a generic geolocation or ASN dataset.

What a custom build does: ingest your routing table properly, ideally via BMP from the border routers so you have the pre policy and post policy views over time, and resolve every flow record against the table as it was at that timestamp rather than as it is now. Sampling gets handled honestly with confidence bounds shown rather than hidden. And the model keeps a record of your announcements at each fabric, because half the peering questions that matter are about inbound traffic that you cannot control directly and can only influence through what you announce and how.

Problem 4: nobody checks whether the session you turned up actually worked

You turn up a session. Traffic appears on it. Everyone declares victory. Six months later the transit bill is the same, because the traffic that moved to the peer was off peak, or because a CDN rebalanced and put it back on transit, or because the peer depreferenced your routes after a capacity event and never told you.

Nothing in the standard toolkit closes this loop, because closing it requires knowing what you predicted, which requires having made a prediction that was recorded. Most organisations never wrote the prediction down.

What a custom build does: store the model output at decision time as a commitment, then measure the actual percentile movement after turn up against it. The result is unglamorous and extremely useful: after a few cycles you learn which of your assumptions are systematically optimistic, and the model gets calibrated against your own network rather than against a vendor's marketing. It also catches silent regressions. A peer whose traffic quietly drops to a fraction of what it was is a route policy change on their side, and you want that as an alert rather than as a discovery during next year's budget.

The same machinery answers the on net cache question. Netflix Open Connect, Google Global Cache and Akamai's on net programmes each move a specific and measurable slice of traffic off your transit, and whether a cache earns its rack space depends on your peak intervals and your commit position, not on the headline volume. Once you have the percentile decomposition, that becomes an arithmetic question rather than a debate.

What a peering and transit cost build costs and how long it takes

From Digital Heroes delivery experience, a first release covering flow ingestion at your volumes, routing table integration, percentile reconstruction with prefix level attribution, and candidate peering modelling against contract terms runs $60,000 to $130,000 and ships in 10 to 14 weeks. A full platform adding commit optimisation across multiple suppliers, IX port sizing, on net cache modelling, session payback tracking and alerting on route policy changes runs $150,000 to $350,000 phased over 6 to 10 months.

What drives cost up specifically here: flow volume, because the difference between ingesting a few thousand and a few hundred thousand records a second is an architecture decision, not a configuration. The number of border routers and vendors, since flow export and BMP behave differently across platforms. Historical retention, because holding a year of prefix level detail rather than aggregates is a storage design problem with a real bill attached. And contract complexity, if you carry tiered pricing, regional commits and blended rates across several suppliers rather than one clean agreement.

What keeps cost down: starting with your two largest transit suppliers and a single exchange fabric, and holding aggregates beyond ninety days rather than full detail forever. Most of the decisions you need to make live in the last quarter.

When Kentik, Deepfield or Flowmon is the right answer

Buy if what you need is visibility. Kentik is a strong product, the analytics are good, and for a network that wants to see traffic by ASN, spot anomalies and answer engineering questions quickly, it does the job without you writing a line of code. Deepfield is built for carrier scale subscriber and DDoS work. Flowmon is a reasonable choice where the primary driver is security. If your transit spend is modest, or if you are on a flat commit you never approach, buying visibility is the correct decision and building your own is a hobby.

Our position on when to build: when two or more of these are true. Your transit and IX spend is large enough that a few percent is a real number to your CFO. You buy from multiple suppliers on differing commercial terms and want the arithmetic done under those terms. Your route policy is complex enough that public ASN mapping disagrees with your RIB. You are evaluating peering or cache deployments regularly rather than once. Or you have been burned by a session that was supposed to save money and did not.

The tipping point is that visibility products model traffic, and your problem is a commercial optimisation over traffic under contracts they cannot see. Once the contract arithmetic is the hard part, the contract arithmetic has to be in the software, and it is yours alone.

How to choose a developer for peering and transit analytics

Ask them to explain percentile billing back to you before anything else. If they talk about monthly averages or total bytes, stop. The right answer involves five minute samples, ranking, and the observation that the bill is set by a small number of intervals, and a developer who says that unprompted has done this work.

Ask how they would resolve a flow record to a destination ASN. The weak answer is a public IP to ASN dataset. The strong answer is your own routing table at the timestamp of the record, ingested via BMP where the platform supports it, with a fallback that is clearly labelled as approximate.

Ask what they will do about sampling. A developer who has run flow analytics at scale will bring up sampling rates and confidence bounds without being prompted, and will refuse to present a sampled number as exact. That single instinct separates people who have done this from people who have read about it.

Ask who owns the code, the repository and the infrastructure, and put it in the contract before kickoff rather than in a schedule at the end. At Digital Heroes the client owns it from the first commit. A good first step before you commission anything: pull one month of flow data and one transit invoice, and ask a developer to reproduce the billed number from your own data. If they cannot do that, nothing built on top of it will be trustworthy.