|
In the run up to the WCIT negotiations in December, the most talked about proposed change to the ITRs (International Telecommunications Regulations) is the ETNO proposal. Most of the discussion centers around the clause;
“For this purpose, and to ensure an adequate return on investment in high bandwidth infrastructures, operating agencies shall negotiate commercial agreements to achieve a sustainable system of fair compensation for telecommunications services and, where appropriate, respecting the principle of sending party network pays.”
Much of the discussion has focused on how this would deter innovation, hamper start-ups and make Internet access much more expensive. Overlooked thus far are the unintended consequences of how this proposal will affect the Content Distribution Network (CDN) industry while simultaneously making cybercrime much easier.
CDNs store content for their customers in various PoPs around the globe to ensure faster delivery to eyeball networks. It’s a useful and sustainable business model, as CDN provide valuable services that folks are willing to pay for. However, if the ITRs are amended to include “sending party network pays” will these CDNs be seen as the sending party and therefore be asked to pay for delivery of their customer’s content thus making their services more expensive to their customers or will they be seen as simple intermediaries, and the source of the content be seen as the sending party? It is conceivable that carriers would even try to “triple dip” with sending party pays, receiving revenue from subscribers, CDNs and content providers for the same traffic.
In the (hopefully) unlikely event that the ITRs are amended with a sending party pays clause, the answer to the above question would be in the details of the implementation. As well as the above direct threat to the CDN business model, there are indirect threats as well. CDNs place their PoPs inside eyeball networks (or at IXPs) whenever possible. With sending party pays, carriers would no longer have an incentive to host CDN PoPs within their networks, as they would not receive revenue if content was already cached inside the carriers network. This would result in greater latency, jitter and bandwidth consumption globally.
CDN deployment (which is especially useful in the developing world) would come to a halt in such a scenario. As an example, in recent years Google has put in Google Global Cache machines at a number of IXPs and in ISPs networks in Africa (and elsewhere). This has resulted in order of magnitude (or lager0 growth in network traffic at these African IXPs. This is “local content” in the sense it does not need to come from the US or the EU on expensive international links. These deployments are positive step for the development of the Internet in Africa, but if ISPs can make more money by removing them, it is hard to see why they would keep a GGC on their network.
It is much easier to foresee how exactly a “sending party network pays” could make the life of cybercriminals much easier and more profitable. If a botnet herder wanted to make some quick extortion cash from a network provider, all they would have to do is to threaten to send loads of traffic from a network to a variety of providers. It’s conceivable that some ISP would accede to the demands of bot-herders or even collude with them to have traffic terminate on their network.
It would be trivial for even “script kiddies” to direct their “zombies” on a targeted network to cause network traffic to increase from the target (much as they do today with DDOS attacks) but this would be the inverse, where traffic flows out of the network which means that network pays. While this is certainly an “innovative business model”, I suggest it is not one that is in the public interest.
The ETNO proposal is a bad idea for a variety of reasons, not least of which is the threat to legitimate business models and the promise of illegitimate ones. I would rather see ETNO members fix their own business models if they are not sustainable.
Sponsored byCSC
Sponsored byVerisign
Sponsored byRadix
Sponsored byDNIB.com
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byIPv4.Global