Peering, IXP Presence, and Private Interconnects for Streaming

Why this matters

If your product ships any meaningful volume of video, the path your bytes take from your origin to your viewers' eyes has a larger effect on cost and quality than almost any other engineering decision you make. A well-peered route shaves tens of milliseconds off startup time, cuts rebuffer rates by a measurable amount, and at scale lowers the bill by half or more compared with raw transit. The reader for this article is the head of platform deciding whether to ask the CDN for an Internet Exchange Point peering report, the founder being told their viewer experience in Eastern Europe is "a peering problem", and the engineer who needs to translate "we're paying for transit we shouldn't be" into a project plan. We assume zero prior knowledge — by the end you will know what every term in the previous paragraph means.

What peering actually is, in plain language

The internet is not one network; it is roughly 75,000 networks, each one run by a company, a university, a government, or a service provider, and each one with its own block of internet addresses and its own routers. These networks are called Autonomous Systems, abbreviated AS, and the number assigned to each one is its AS number. Comcast is AS7922. Netflix is AS2906. Cloudflare is AS13335. Google is AS15169. Your own little corporate office probably doesn't have one, because you connect through one of the big ones.

Now imagine you are Network A and you want to send a packet to Network B. There are exactly three ways for that packet to get there. First, you can hand it to a third network — a transit provider, sometimes called a tier-1 carrier — that already has agreements with both you and B, and you pay them per megabit per second to carry it. Second, you and Network B can agree to connect to each other directly, shake hands on a router-to-router link, and exchange the packet for free or for a flat port fee. Third, you can put a copy of the content B is fetching from you onto a server you have placed inside Network B's own facility, so the request never crosses a billable link at all.

That second arrangement — direct exchange of traffic between two networks — is peering. The third arrangement — putting a cache or appliance inside the other network — is on-net caching, which is a separate animal we will get to. Almost every streaming bill conversation comes down to which of these three you are using, and in what proportion.

The word "peering" is also used loosely to mean the whole family of direct-exchange arrangements. We are about to split that family into its real subtypes.

Public peering: the Internet Exchange Point

An Internet Exchange Point — abbreviated IXP — is a physical building, almost always a carrier-neutral data centre, that hosts a shared layer-2 switching fabric. You rent a port on that fabric, plug your router in, and from that one port you can establish peering sessions with hundreds of other networks that have also plugged in. The big European IXPs make the model concrete: DE-CIX Frankfurt advertises around 400,000 IPv4 prefixes and 130,000 IPv6 prefixes reachable through its route servers, with aggregate traffic in the 10–20 Tbps range as of January 2026 according to PeeringDB. AMS-IX in Amsterdam, LINX in London, MSK-IX in Moscow, Equinix's various IX fabrics in Ashburn, São Paulo, Singapore, and Sydney — these are the platforms where the world's networks meet.

The economic shape is friendly to a new entrant. You pay the IXP operator a monthly port fee, typically a few hundred to a few thousand dollars for a 10G or 100G port. You pay the carrier-neutral data centre a monthly cross-connect and rack fee. And then, with every other network on the same fabric that agrees to peer with you, you exchange traffic at zero per-bit cost. This zero-marginal-cost exchange is called settlement-free interconnection, or SFI, and it is the financial foundation of the open internet.

The volume of traffic an IXP-based peering programme can shift surprises engineers who haven't seen it. The Internet Society's 2026 interconnection analysis frames the trend as a structural transformation, not a decline — IXPs are still where the long-tail networks of the world meet, and they are layering in new capabilities to handle enterprise AI workloads on top of the legacy peering function. In Italy, traffic peaks driven by live sports streaming have visibly amplified peering volumes at the national IXPs, and the same pattern shows up in every market where a domestic streaming platform has reached scale.

The catch is that public peering is public. The fabric is shared. If one of the other tenants on the IXP misbehaves — broadcasts a wrong route, suffers a denial-of-service attack, loses a router — your traffic can be affected. The IXP operator polices the fabric, but you do not own it. For most streaming use cases this is fine; for a premium broadcast feed that cannot tolerate a single bad minute, it is not.

Private peering: the Private Network Interconnect

A Private Network Interconnect, abbreviated PNI — sometimes called a private peer or, by the cloud providers, a "Direct Connect", "Cloud Interconnect", or "ExpressRoute" — is a dedicated cable that runs from your router straight to another network's router. No shared fabric, no other tenants, no broadcast domain to be poisoned. Inside a single carrier-neutral data centre, the PNI is often literally a fibre patch lead that costs a few hundred dollars a month to provision. Across data centres or across cities, it is a leased dark fibre or wave, and the price climbs accordingly.

The performance case for PNIs is unambiguous at scale. Cloudflare's network-interconnect launch blog post documents a customer in Warsaw whose ninetieth-percentile round-trip time fell from 7.5 milliseconds to 1 millisecond after multiple PNIs were provisioned — an 87% improvement on the most important latency metric a streaming engineer tracks. Round-trip time directly drives TCP throughput, manifest fetch time, segment download time, and player startup time. Shave six milliseconds off RTT for ten million viewers and you have shaved real money off rebuffer counters.

The cost case is more nuanced. A PNI carries no per-bit charge, but it consumes a port on both sides, a cross-connect, and operational attention. You need at least two ports for redundancy. You need traffic to justify the spend. The unwritten industry rule of thumb is that you migrate a peering relationship from public IXP to PNI when sustained traffic over the public fabric crosses about 1 Gbps; below that, the PNI's fixed cost dominates and the IXP is cheaper per bit; above that, the PNI's lack of a per-bit meter pulls ahead and you also gain a private, controllable link.

On-net caching: the third lever

The third arrangement deserves its own name because it changes the economics more than either kind of peering. Instead of exchanging traffic between two networks, you place a server inside the other network. The classic examples are Netflix's Open Connect Appliance (OCA) programme and Google's Google Global Cache (GGC) programme. In both, the content provider ships a hardware server, at no cost to the ISP, into the ISP's own facility. The ISP gives it rack space, power, and a high-speed port. The provider's clients in that ISP fetch their video from the local appliance instead of from a peered or transited link out of the ISP. The traffic never crosses a settlement boundary at all.

The numbers are extreme. Netflix's Open Connect documentation reports more than 19,000 OCAs deployed across 1,500-plus ISP locations in over 100 countries as of 2025. Together they shift 100% of Netflix video traffic — over 125 million hours per day, peaking at tens of terabits per second. To qualify for a free OCA, an ISP needs to be moving a minimum of 5 Gbps of Netflix peak traffic; below that threshold the math doesn't justify the hardware, and Netflix instead serves the ISP from the nearest peering point. A large-site deployment is on the order of 10 storage OCAs plus 30 flash OCAs, scaling delivery into the terabit-per-second range from a single rack pair. Google Global Cache plays the same game for YouTube: edge nodes inside more than 1,300 cities serving 70–90% of cacheable Google traffic locally, cutting external traffic on ISP peering and transit links almost to nothing.

This is what people mean when they say "Netflix is not on the internet". A meaningful fraction of Netflix bytes simply never travels a paid network link. The 2016 Open Connect study published on arXiv counts the same observation a different way: Netflix has chosen settlement-free interconnections combined with on-net deployments as its delivery model, instead of paying for transit or running a commercial multi-CDN footprint.

The cost asymmetry is what drives every other strategic decision in this article. A streaming platform that ships a billion video-hours a month pays nothing to deliver the portion served from on-net caches. Whatever fraction does not fit on the cache — long tail content, live events, new releases — is delivered through peering, and only the remainder rides commercial transit. The waterfall is cache first, peer second, transit last, and the order of those terms maps almost perfectly onto the order of their unit costs from cheap to expensive.

Figure 1. The three delivery layers a streaming platform stacks, in order from cheapest to most expensive per byte.

Settlement-free, paid peering, and the traffic-ratio question

Not every peering relationship is settlement-free. Some are paid peering, where one side writes a per-bit cheque to the other side, even though the bytes never traverse a transit network. The reason this exists is the traffic-ratio rule that almost every large eyeball ISP keeps in its peering policy.

The rule is straightforward. Two networks that peer settlement-free should send roughly the same volume of traffic to each other in both directions. The conventional cutoff is a 2:1 ratio of inbound to outbound traffic. If you push more than twice as much traffic to the ISP as the ISP pushes back to you, the ISP starts to argue that the relationship is not balanced and that it incurs costs delivering your bytes to its customers without symmetric benefit.

This rule was written for a world where every network was assumed to be roughly symmetric. Streaming broke the assumption. A 2024 NSF-funded paper by Nikkhah and Jordan estimates that about 80% of internet traffic is video, and video is fundamentally a one-way stream from content provider to viewer. A content delivery network has nothing meaningful to pull back from an eyeball ISP — there are no subscribers behind a CDN whose upstream traffic could balance the downstream feed. By the strict reading of the traffic-ratio rule, almost every CDN-to-ISP relationship fails the test, and an ISP could refuse settlement-free peering with any of them.

In practice the rule bends. Most large ISPs maintain settlement-free peering with the big CDNs because the alternative — forcing the CDN to deliver bytes via transit, or charging the CDN per bit — creates worse outcomes for the ISP's own subscribers, who care about Netflix and YouTube working well. The famous 2014 Comcast–Netflix paid-peering dispute is the exception that proves the rule: in that period, Comcast and Netflix could not agree on settlement-free terms, Comcast traffic to Netflix degraded, the public called Comcast, and the dispute resolved through a paid-peering deal that was widely understood as a Netflix concession. After that episode, both sides retreated to the pre-existing equilibrium of mostly-settlement-free CDN-to-ISP peering, with occasional paid arrangements where one side has a hard policy.

The lesson for a smaller streaming platform: assume settlement-free with the CDNs that already have ISP relationships, and assume mostly-paid if you are negotiating directly with an eyeball ISP at your own AS. The peering policy on the ISP's website tells you which it is — most large ISPs publish theirs, and they list traffic-ratio thresholds, port-redundancy minima, and presence requirements (typically that you have a router in at least three of the ISP's preferred meet-me-rooms across the continent).

The math: when does peering pay back?

A streaming platform's peering decision is not a matter of taste; it is a per-region break-even calculation. The cost components on each side are knowable and stable enough to project.

The transit side is metered. Quality IP transit at scale runs about $0.50 to $1.00 per Mbps per month of 95th-percentile bandwidth in well-served markets in 2026 — Tier-1 carriers in Frankfurt, Amsterdam, London, Ashburn — and rises sharply in undersupplied markets like Lagos, La Paz, and parts of Southeast Asia, where the same Mbps can list at $3.00 to $8.00 per month. Pay-as-you-go CDN egress on top of that ranges $0.005 to $0.02 per GB at the volumes large streaming platforms commit to, although headline rate cards quote much higher.

The peering side is mostly fixed. An IXP port runs a few hundred to a few thousand dollars per month for a 10G or 100G port. A carrier-neutral data centre cross-connect runs $200–$500 per month. A PNI cross-connect inside the same facility runs the same; a PNI across cities is a leased wave, $1,500–$8,000 per month for 10G depending on the route.

Now do the math out loud. Suppose your peak traffic to a specific eyeball ISP is 1 Gbps and the relationship is settlement-free at an IXP both you and the ISP are present at.

• IP-transit alternative: 1,000 Mbps × $1.00/Mbps × 30 days/30-day-month = $1,000/month.
• IXP alternative: $1,200/month for a 10G port + $300/month for the cross-connect = $1,500/month.

At 1 Gbps, the IXP is more expensive than transit. But the IXP fee is fixed and gives you settlement-free peering with hundreds of other networks on the same fabric — not just the one ISP. If twenty more ISPs on the same IXP each take 200 Mbps of your traffic, you have moved 5 Gbps off transit at the same $1,500 IXP cost, against $5,000 of transit you would otherwise have bought. The peering is now strongly positive.

This is the structural insight: one IXP port is not paying for one peering relationship; it is paying for dozens at once. The marginal cost of adding the twenty-first peer on the same IXP port is zero. The marginal cost of adding the twenty-first transit-routed ISP is another $200 of bandwidth.

A PNI is a different shape. A 10G PNI in the same data centre at, say, $400/month (cross-connect + port amortisation) is positive against transit as soon as you sustain about 400 Mbps of traffic to a single network. At 1 Gbps to that one network the PNI saves about $600/month. At 5 Gbps it saves about $4,600/month — enough to justify two PNIs for redundancy and still come out ahead. A 2 PB/month streaming platform with a coherent peering and PNI map can save $50,000–$500,000 a month against the same workload on pure transit, which is why every CDN that bills you for delivery has its own peering team negotiating these deals on your behalf.

Figure 2. Where IP transit, IXP peering, and PNI break even as traffic to a single counterpart grows.

Common pitfall: assuming your CDN already has every peer

The single most common mistake mid-sized streaming teams make is to assume that because they buy from a major CDN, their bytes are already peered everywhere that matters. They are not. Every CDN's peering map has holes. A CDN may peer richly in Frankfurt and Ashburn while routing your traffic through São Paulo across a transit link because that particular regional ISP isn't on the CDN's PNI list, or because the CDN's contract with that ISP is paid and the CDN routes around it.

The way to find out is to ask. Every reputable CDN will produce a peering report on request — a per-region breakdown of which networks they reach via IXP, which via PNI, which via transit, and the ratio of cached versus origin-pulled traffic. If your CDN refuses or stalls, that is a procurement signal. The same report exists in inverse from the ISP side: PeeringDB at peeringdb.com is the public registry where networks declare their AS number, their IXP presence, their PNI policy, and their peering email. Looking up your viewers' top ten ISPs in PeeringDB and cross-referencing against your CDN's presence is a one-afternoon exercise that has caught real misroutings at every Fora Soft client engagement of this size.

A second pitfall is misunderstanding the on-net cache option. Teams sometimes assume that because Netflix and Google have on-net caches inside ISPs, they can negotiate the same. They cannot, at least not on equal terms. The OCA and GGC programmes work because the volume justifies free hardware on both sides: a 5 Gbps ISP qualifying floor implicitly means the content provider is moving petabytes-per-month worth of bytes through that ISP. A 100 Mbps streaming product cannot offer an ISP enough value to be worth the rack space. The realistic alternative for products at that scale is a managed CDN whose own caches sit inside the ISP, paid for by the CDN out of its scale across all customers.

Russia, the EU, and regional differences

Peering is not uniform across the world. The country where your viewers live changes the calculus by a factor of two or three.

In Western Europe, dense IXPs at Frankfurt, Amsterdam, London, Marseille, and Vienna mean that most settlement-free peering happens at low cost; the IP-transit market is competitive and prices have fallen for a decade. Settlement-free peering is the default; PNIs handle the largest counterparties. In North America, Ashburn (the Equinix-anchored exchange complex) handles a disproportionate share of US traffic; Los Angeles, Atlanta, Dallas, and Seattle round out the map. In Russia, MSK-IX in Moscow plus Data-IX, Piter-IX in St Petersburg, and several smaller exchanges form the core; the country's largest ISPs (Rostelecom, MTS, MegaFon, Beeline, ER-Telecom) are present and reachable. In Brazil, IX.br in São Paulo is the largest IXP in the world by member count; almost every Brazilian streaming product reaches its audience through it. In India, NIXI exchanges in Mumbai, Chennai, Delhi, and Bangalore are present but smaller; on-net caches and direct PNIs to Reliance Jio, Airtel, and Vi handle the bulk of streaming traffic.

The Internet Society's 2026 regional dynamics report frames the broader trend: peering is structurally consolidating in the major markets and structurally expanding in emerging markets, with IXPs in Africa, Southeast Asia, and Latin America growing the fastest in absolute interconnection capacity year over year. For a streaming platform planning a multi-region launch in 2026 or 2027, the practical answer is: name your top three target countries, look up their main IXPs, see who is present, and design your interconnection map from there before signing a CDN contract.

Working example: a 10 Gbps live-streaming product picks its peering

Consider a hypothetical product — a live-streaming service with 2 million monthly active viewers, peak concurrent 80,000 viewers at 5 Mbps average per stream, 60% of viewership in the US, 20% in Western Europe, 20% in Eastern Europe. Peak egress works out to about 400 Gbps total, split roughly 240 Gbps US, 80 Gbps Western Europe, 80 Gbps Eastern Europe.

A purely transit-routed approach in 2026 would cost roughly 400,000 Mbps × $0.70/Mbps blended = $280,000/month for the bandwidth alone, plus the per-GB CDN egress on top.

A CDN-only approach, using a major commercial provider at a $0.010/GB committed rate, would carry the same workload at roughly 400 Gbps × 8 bits/byte × 86,400 s/day × 30 days × 0.5 day-utilisation × $0.010/GB ÷ 8e9 bits/GB ≈ $52,000/month, with the CDN absorbing the peering inside its own platform.

A direct-peering approach with the platform present in Ashburn (Equinix IX), Frankfurt (DE-CIX), and a Moscow-region IXP runs roughly $4,500/month in port and cross-connect fees, plus three to five PNIs to the largest regional ISPs at $400/month each — total fixed interconnection cost around $7,000/month. Of the 400 Gbps peak, perhaps 70% lands on a peered or PNI-served path; the remaining 30% still rides commercial transit or CDN egress for the long tail and uncached events. Effective bandwidth bill is roughly $7,000 fixed + (120 Gbps × 0.5 utilisation × $0.70/Mbps × 30 × 1000) = $7,000 + $1,260,000? — no, recompute: $0.70/Mbps × 120,000 Mbps = $84,000/month transit for the 30% tail, total $91,000/month.

That last number is higher than the CDN-only approach because we are not absorbing the CDN's scale benefit. The point of the worked example is that for most products under about $250,000/month CDN spend, hiring a major CDN is cheaper than running your own interconnection map; above that, the peering route starts to win. This is why almost every CDN bills you a per-GB rate that bakes in their own peering savings without showing them on the invoice — they are running the peering math at a scale you cannot match alone.

Where Fora Soft fits in

At Fora Soft we have built the streaming side of more than 239 video products since 2005, across video conferencing, OTT/Internet TV, telemedicine, e-learning, and surveillance. We are not a CDN, and most of our clients are not large enough to run their own peering programmes. Our role on this topic is usually one of three: helping a CTO read the peering report their CDN already produces, designing a multi-CDN setup that uses content steering to route per-region based on real-world performance, or sizing an architecture where on-net or near-on-net delivery is the next step the product needs as it scales. We have seen the difference a single PNI to a regional ISP can make to a telemedicine product whose users are mostly on one carrier, and we have seen products outgrow their single-CDN choice and need to engineer around it.

What to read next

• CDN cost economics: 95th-percentile, commit, overage, transit — the meters that price the bytes peering moves.
• Multi-CDN: architecture, cost story, failure modes — why every large platform runs at least two CDNs.
• Content steering: the standard way to do multi-CDN — how the player chooses the best peered path in real time.

CTA block

• Talk to a streaming engineer — scope a session on your interconnection map and CDN peering with our team.
• See our case studies — real-world OTT, conferencing, and telemedicine systems we have built.
• Download the peering-readiness checklist — a 1-page PDF you can take into a CDN procurement meeting.

Download the peering-readiness checklist

References

1. Netflix Open Connect — "Open Connect Overview" (PDF on openconnect.netflix.com, accessed 2026-05-24). Source for OCA programme, free hardware to qualifying ISPs, 5 Gbps qualifying floor, 2U appliances scaling to terabits per second.
2. Open Connect deployment statistics — Plixer / blazingcdn summary citing Netflix 2025 figures of 19,000+ OCAs across 1,500+ ISP locations in 100+ countries, 125 million hours/day, tens of Tbps peak. Cross-checked against the Netflix Open Connect Overview PDF.
3. Google Global Cache — Wikipedia (en.wikipedia.org/wiki/Google_Global_Cache, accessed 2026-05-24). Source for GGC mechanics, 70–90% local cacheable-traffic figure, 1,300+ city deployment count.
4. PeeringDB — DE-CIX Frankfurt record (peeringdb.com/ix/31, accessed January 2026 snapshot). Source for ~400,000 IPv4 prefixes / 130,000 IPv6 prefixes / 10–20 Tbps aggregate traffic.
5. Cloudflare blog — "Introducing Cloudflare Network Interconnect" (blog.cloudflare.com/cloudflare-network-interconnect, accessed 2026-05-24). Source for Warsaw PNI case study with 87% RTT reduction at the 90th percentile.
6. Nikkhah & Jordan — "Are the Settlement-Free Peering Policy Requirements for ISPs and CDNs Based on Network Costs?" (NSF / ACM, 2024). Source for traffic-ratio analysis, 80% video share, 2:1 threshold rationale.
7. Internet Society Pulse — "Trends, Transformations, and Regional Dynamics of Internet Interconnection" (pulse.internetsociety.org, March 2026). Source for 2026 regional dynamics framing, emerging-market IXP growth, IXP capability evolution.
8. Equinix blog — "What Are Internet Exchanges? Why Do They Matter Today?" (blog.equinix.com, March 2026). Source for IXP role in modern application delivery and the IXP-as-interconnection-platform framing.
9. HorizonIQ blog — "Despite Comcast-Netflix deal, settlement-free peering is alive and well" (horizoniq.com, accessed 2026-05-24). Source for the 2014 Comcast–Netflix paid-peering dispute context.
10. Skip2 Networks blog — "Public vs. Private Peering: How Networks Connect" (skip2.net/blog/public-vs-private-peering, accessed 2026-05-24). Source for the public-vs-private peering taxonomy used throughout.
11. arXiv 1606.05519 — Böttger et al., "Open Connect Everywhere: A Glimpse at the Internet Ecosystem through the Lens of the Netflix CDN" (2016). Academic measurement of Netflix's settlement-free + on-net deployment strategy.