I'm hearing a lot of discussion at the moment about peering being the new battleground for "non-neutrality" of networks, and especially a mechanism for operators to try and monetise traffic from Internet/video providers.
In theory, the argument goes along the lines of "symmetrical peering is fine, but if there's heavy asymmetry, eg mass downloads outweighing uploads, then we've got a right to renegotiate our deals with our Internet peers".
Surely, this is just going to result in Netflix, Google, BBC and others developing new services that are predominantly upload-centric, to try and redress the balance of traffic? Rather than either reducing downloads, or actually paying cold hard cash?
So instead of combatting traffic load, this surely just encourages Google to offer realtime augmented reality with video-processing in the cloud, clogging uplink as well as downlink? Or for the BBC to archive your old VHS tapes somehow? Or for Apple to push an audio "black box" that records all your ambient sounds during the day & streams them to a server? Or for all of them to start using peer-to-peer techniques for content distribution? (all of this encrypted and hidden from DPI, obviously).
This is just an idle musing for now, and I've never seen the details of a peering arrangement. I guess there could be some way of tying it to actual congestion (eg traffic from YouTube that gets downloaded in busy cell / busy hour is accounted for differently to that during quiet periods). But in that case, there would need to be some serious OSS/BSS integration work to actually be able to *prove* this
In theory, the argument goes along the lines of "symmetrical peering is fine, but if there's heavy asymmetry, eg mass downloads outweighing uploads, then we've got a right to renegotiate our deals with our Internet peers".
Surely, this is just going to result in Netflix, Google, BBC and others developing new services that are predominantly upload-centric, to try and redress the balance of traffic? Rather than either reducing downloads, or actually paying cold hard cash?
So instead of combatting traffic load, this surely just encourages Google to offer realtime augmented reality with video-processing in the cloud, clogging uplink as well as downlink? Or for the BBC to archive your old VHS tapes somehow? Or for Apple to push an audio "black box" that records all your ambient sounds during the day & streams them to a server? Or for all of them to start using peer-to-peer techniques for content distribution? (all of this encrypted and hidden from DPI, obviously).
This is just an idle musing for now, and I've never seen the details of a peering arrangement. I guess there could be some way of tying it to actual congestion (eg traffic from YouTube that gets downloaded in busy cell / busy hour is accounted for differently to that during quiet periods). But in that case, there would need to be some serious OSS/BSS integration work to actually be able to *prove* this
1 comment:
Peering is simple
1) ISP's generally collaboratively connect to each other, ether directly or through an exchange (e.g. LINX). These are generally symmetric and costs are shared.
Google is very good at working with ISP's to directly provide this connectivity and directly peers with most ISP's
2) Transit. In order to connect to non-peered networks, you have to transit another network (e.g. level 3 or global crossing) which then connects to the other network. The BBC moved iPlayer hosting in to level 3 some years ago as it saved the bbc costs (because Level 3 managed all the other network connectivity), See;
http://www.telco2.net/blog/2008/08/bbc_iplayer_bandwidth_wars.html
http://www.thinkbroadband.com/news/3663-bbc-faces-criticism-on-iplayer-hosting-change.html
The content provider has a huge impact on ISP costs - if they increase the peering costs by using a transit provider who will charge the ISP's for bandwidth.
So, its not all smoke and mirrors ;)
also there is an easy way of dealing with this, to cut the connectivity (and thus "neutrality") of certain links which will affect services.
Post a Comment