A group of the UK's largest fixed and mobile ISPs have published a "Code of Practice" about managing traffic on their broadband networks. The full document is here with the announcement press release here. The group includes BT, Vodafone, 3, O2, Virgin, BSkyB and TalkTalk, but currently excludes others, notably EverythingEverywhere, the Orange/T-Mobile joint venture.
(Regular readers may remember that I put up a suggested draft Code of Conduct for traffic management last year - there seems to be a fair amount that has been picked up in the UK document. My input also fed into the manifesto published my partners at Telco 2.0, here)
There's some good stuff, and some less-good stuff about the new Code of Practice. Of course, if you a Net Neutrality purist, your good/bad scale will shift a bit.
On the positive side, the general principle of transparency is extremely important. The committment to being "Understandable, Appropriate, Accessible, Current, Comparable, Verifiable" is entirely the right thing to do. I think there is a lot of good stuff in the Code here, going as far as the need for independent verification (although that would probably happen anyway - I'm sure Google and others have their own techniques for watching how traffic shaping is used by telcos).
The fact that it has been signed by both fixed and mobile operators is also a good thing, although there isn't much in the document about the specific issues inherent in wireless networks.
But the main problem is that it attempts to define traffic management policies by "type of traffic" in terms of descriptions that are only meaningful to boxes in the network, not to users themselves. Ironically, this fails the Code's own insistence on being understandable and appropriate. There are also no clear definitions on what constitutes the various categories such as "gaming" or "browsing".
The problem here is that DPI boxes don't really understand applications and services in the way that users perceive them. "Facebook" is an example of an application, including links or video which are displayed on the web page or inside a mobile app. "WebEx" is another application, which might include video streaming, messaging, file transfer and so on. Add in using HTML5 browsers and it all gets messier still.
Having a traffic policy that essentially says "some features of some applications might not work" isn't very useful. It's a bit like saying that you've got different policies for the colour red, vs. green. Or that a telephone call is #1 priority, unless a voice-recognition DPI box listens and senses that you're singing, in which case it gets reclassified as music and gets down-rated.
And even in terms of traffic types, the CoP conspicuously misses out how to deal with encrypted and VPN traffic, which is increasingly important with the use of HTTPS by websites such as YouTube and Facebook. Given that SSL actually is a protocol and "traffic type" this is pretty important. At the moment, the footnote "***If no entry is shown against a particular traffic type, no traffic management is typically applied to it." to me implies that encrypted traffic passes through unmolested under this code of practice. (I'd be interested in a lawyer's view of this though).
Another problem is that there is an assumption that traffic management is applied only at specified times (evening, weekends etc), and therefore not just when or where there is *actual* congestion. I suspect Ofcom will take a dim view of this - my sense is that regulators want traffic management to be proportionate and "de minimis" and there seems no justification for heavy-handed throttling or shaping when there is no significant congestion on the access network or first-stage backhaul.
There is also no reference to what happens to any company which fails to meet its obligations under the Code (which is "voluntary"), or how enforcement might happen in the future.
Lastly, there is no reference to bearer-type issues important in mobile. In particular, whether the same policies apply to femtocell or WiFi offload.
Overall, on first read I'd give it a 5 out of 10. A useful start, but with some serious limitations.
(Regular readers may remember that I put up a suggested draft Code of Conduct for traffic management last year - there seems to be a fair amount that has been picked up in the UK document. My input also fed into the manifesto published my partners at Telco 2.0, here)
There's some good stuff, and some less-good stuff about the new Code of Practice. Of course, if you a Net Neutrality purist, your good/bad scale will shift a bit.
On the positive side, the general principle of transparency is extremely important. The committment to being "Understandable, Appropriate, Accessible, Current, Comparable, Verifiable" is entirely the right thing to do. I think there is a lot of good stuff in the Code here, going as far as the need for independent verification (although that would probably happen anyway - I'm sure Google and others have their own techniques for watching how traffic shaping is used by telcos).
The fact that it has been signed by both fixed and mobile operators is also a good thing, although there isn't much in the document about the specific issues inherent in wireless networks.
But the main problem is that it attempts to define traffic management policies by "type of traffic" in terms of descriptions that are only meaningful to boxes in the network, not to users themselves. Ironically, this fails the Code's own insistence on being understandable and appropriate. There are also no clear definitions on what constitutes the various categories such as "gaming" or "browsing".
The problem here is that DPI boxes don't really understand applications and services in the way that users perceive them. "Facebook" is an example of an application, including links or video which are displayed on the web page or inside a mobile app. "WebEx" is another application, which might include video streaming, messaging, file transfer and so on. Add in using HTML5 browsers and it all gets messier still.
Having a traffic policy that essentially says "some features of some applications might not work" isn't very useful. It's a bit like saying that you've got different policies for the colour red, vs. green. Or that a telephone call is #1 priority, unless a voice-recognition DPI box listens and senses that you're singing, in which case it gets reclassified as music and gets down-rated.
And even in terms of traffic types, the CoP conspicuously misses out how to deal with encrypted and VPN traffic, which is increasingly important with the use of HTTPS by websites such as YouTube and Facebook. Given that SSL actually is a protocol and "traffic type" this is pretty important. At the moment, the footnote "***If no entry is shown against a particular traffic type, no traffic management is typically applied to it." to me implies that encrypted traffic passes through unmolested under this code of practice. (I'd be interested in a lawyer's view of this though).
Another problem is that there is an assumption that traffic management is applied only at specified times (evening, weekends etc), and therefore not just when or where there is *actual* congestion. I suspect Ofcom will take a dim view of this - my sense is that regulators want traffic management to be proportionate and "de minimis" and there seems no justification for heavy-handed throttling or shaping when there is no significant congestion on the access network or first-stage backhaul.
There is also no reference to what happens to any company which fails to meet its obligations under the Code (which is "voluntary"), or how enforcement might happen in the future.
Lastly, there is no reference to bearer-type issues important in mobile. In particular, whether the same policies apply to femtocell or WiFi offload.
Overall, on first read I'd give it a 5 out of 10. A useful start, but with some serious limitations.
No comments:
Post a Comment