Sometimes what is important about a report or statement is what is not said. In the case of a report discussing European Union region network infrastructure issues, the European Commission did not issue an explicit decision whether a few large app providers (Netflix, Meta, Google) should be required to pay fair share fees to internet access providers.
Some observers might argue that likely means no action, one way or the other, will be taken in the next year or so.
Though other issues were noted by the report, including the coming role of network virtualization artificial intelligence, edge computing, a unified EU market and open networks, the immediate battle is over revenue. ISPs and mobile operators say their revenues and profit margins are declining, and the argument is that this is, in large part, because a few large content and app providers benefit from ISP networks without contributing to create the needed capacity of those networks.
Critics might note that internet domains--including the targeted hyperscale firms--already pay such fees for traffic asymmetry in the form of interconnection payments.
Hyperscale App Provider | ISP | Interconnection Payment |
Netflix | Comcast | $1 billion |
Netflix | Verizon | $750 million |
Amazon Web Services | Comcast | $1.2 billion |
Amazon Web Services | Verizon | $900 million |
Microsoft Azure | Comcast | $1 billion |
Microsoft Azure | Verizon | $750 million |
Google Cloud | Comcast | $800 million |
Google Cloud | Verizon | $600 million |
Microsoft Azure | AT&T | $75 million per year |
Alphabet | Charter | $100 million per year |
Amazon | AT&T | $150 million per year |
Microsoft | Charter | $75 million per year |
Google | AT&T | $125 million per year |
Meta | Charter | $50 million per year |
Meta | AT&T | $75 million per year |
Alphabet | China Telecom | $150 million per year |
Amazon | NTT | $125 million per year |
Microsoft | Deutsche Telekom | $100 million per year |
Google | Telefónica | $75 million per year |
Meta | Singtel | $50 million per year |
Meta | Orange | $75 million per year |
In addition, one can clearly argue that ISPs charge their own customers for internet access service, and can set those fees at levels that support their own customers’ data consumption. Already, some heavier users pay more than lighter users, and that is a business decision any ISP is free to make.
In other businesses, when the cost of a product goes up, so does the retail price. In other words, if their own consumers are consuming more capacity than present retail prices recover, raise prices.
The other angle is that, traditionally, traffic imbalances between domains were assumed to be created by the initiating party. For example, the party placing an international call pays for the call. The party sending a text message pays for it.
The claimed traffic imbalance ISPs complain about is created by requests from their own customers for app providers to send data.
That noted, in the past it was the telcos themselves that created interconnection payments for traffic asymmetries. Even in the internet era, where the hyperscale app providers often create their own end-to-end networks, traffic imbalances result only when a customer on one ISP network requests content from a firm on another ISP’s network.
In other words, interconnection obligations happen when one party invokes the use of another party on a different network. At a retail level, the initiating customer creates a session that generates revenue for the initiating and terminating networks. At a wholesale level, imbalances between networks and domains are resolved either by settlement-free peering or true-ups at the end of a year.
This is arguably more complicated than in the past, in part because internet sessions are based on nailing up circuits for finite periods of time easy to measure. Also, the locations of requesting and fulfilling parties is not set.
The party requesting content can be on the same ISP network as the requesting party, in which case no inter-domain traffic is invoked. The requesting party can be on network A, while the fulfilling party is on network B, but, on balance, requesting and fulfilling parties exist--in many cases--on both neworks A and B.
At a high level, traffic might roughly balance over a year’s time, especially in cases where ISPs A and B have hyperscale data centers as customers “on their own networks,” as well as retail customers invoking delivery of content from firms at those data centers, both on networks A and B.
At one level, one might argue that peering makes more sense on transit and wide area networks since the actual path any packet might take is indeterminate. Any WAN provider might be able to cite the total number of packets flowing over the network, but be unable to identify which originating networks were involved in creating the traffic.
On any access network, in contrast, the use of network resources is definite. No matter what path packets might take across the interconnected wide area networks, they use only one physical path at the receiving party’s location on the local access network.
But again, one might ask: is the “cause” of traffic imbalance the originator or the fulfiller of a session? Is it the ISP customer asking for streaming of a Netflix movie the traffic initiator, or is it Netflix fulfilling the request?
Beyond that, is it the ISP supporting Netflix content delivery that is “creating the traffic asymmetry” or is it Neflix or the Netflix customer on the ISP network that asks for the content?
Without question, domain interconnection, what constitutes a “session” and “who initiated the session?” are different questions in the internet era than was the case in the voice era.
But the issues are bigger than that. In the internet era, transport and access service providers have lost their “closed” networks and the ability to control the presence of every app that uses the network, by and large.
In a “permissionless” era, where no app creator needs a formal business relationship with a capacity provider to reach a customer, ISPs also have lost the ability to monetize their traffic as owners of such third-party apps.
In a real sense, the proposed “fair share” payments from a few hyperscale app providers to ISPs is an effort to recreate that revenue mechanism.
Or, in other words, “fair share” is an effort by ISPs to participate in the revenue earned by a few hyperscale app providers, as would have been the case in the older world of “closed” networks, where all apps needed permission from the network owner to operate.
