Net neutrality today — playing the "safety" card
Net Neutrality is Bad for National Preparedness, says Center for Advanced Studies
NEW YORK, June 12 /U.S. Newswire/ — In a research brief published by the World Policy Institute's Global Information Society Project, K.A.Taipale, executive director of the Center for Advanced Studies, Science & Technology Policy, asks whether imposing strict net neutrality regulation on telecommunications providers could put public safety and economic recovery at risk in times of national emergency.
How quickly can an innovation policy question be morphed into a security issue? Answer: Almost instantly.
All the incumbents familiar to us in internet policy questions — law enforcement, Hollywood, and the telcos — share an interest in deep packet inspection. They all want to protect their existing, old-world business models.
Law enforcement wants deep packet inspection because they have an insatiable desire for information (even if they have trouble parsing what they get). Hollywood wants it because they want to know who's watching their movies, so they can shield their distribution windows. And the dominant telcos want it so they can prioritize traffic and cableize internet access.
Watch this move. We'll be seeing much more of this. DHS would like to ensure that its packets get priority. They'd like to change the essential internet protocols to make this possible. As a society, we have to decide whether ensuring security (of DHS, of Hollywood, of the telcos) is worth the costs to our future such tinkering will cause.
Comments
10 Responses to “Net neutrality today — playing the "safety" card”
Got something to say?
Dear Susan,
The concerns that Kay raised are appropriate, timely, and critical for the national and global public communication infrastructures. They are also not new, and have nothing to do with “deep inspection.”
Since the inception of public communication systems, because they are critical to societal and governmental functioning, mechanisms have been instituted to control traffic flows based on priortization. You can find related provisions in the very first international agreements such as the Dresden Treaty of 1850. These capabilities are especially critical during times of national emergency or network restoration.
Today, as public communication infrastructures worldwide increasingly become reliant entirely on TCP/IP protocols, means are necessary to control access and provide varying quality of service on a service and user basis. Much of this work has already been accomplished over the past several years in the context of IMS and NGN work. You should also review the work of the NSTAC - which has existed since the early 80s after the AT&T breakup - in treating this subject.
What Kay is pointing out is that some of the NetNeutrality provisions being bandied about in legislation are antithetical to long-standing concerns about our critical national communications infrastructure. Those are concerns we should all share.
It is apparent that people still don't understand that prioritized services will work very poorly at their best on the Internet. Pay all you want to prioritize traffic, but in the end, its unlikely that any performance improvement will be consistent at all, if even consistently noticeable.
In order for the priority settings in traffic packets to actually work in a way that would support 'national emergency needs', each and every piece of equipment running the global Internet would need compatible configurations with respect as to how to classify and treat the many IP priority settings that any given IP packet can have.
What this means that that even if telcos are allowed to implement traffic prioritization, any notion that this would help in time of an emergency is vaporous at its best. In fact, the thought that since telcos can use prioritization as some kind of panacea to cure congestion ills on the Internet at large would invariably lead to unfulfilled expectations on the part of the consuming public.
Also, the deeper the packet inspection, the less likely that traffic prioritization will actually result in measurable and consistent improvements in traffic flow on the Internet.
The problem is further complicated by the fact that much of the planet's Internet Protocol traffic flows through US borders. If the government did issue regulations on how to prioritize traffic, and then somehow enforced such regulations (the only way that prioritization will have enough of an impact to be noticeable), most of the rest of the world will be subject to those regulations.
bithead, the Cable companies prioritize traffic on their wires and have as long as they're been using DOCSIS. Local law enforcement and emergency services can use priorities within the cable and FIOS networks just fine.
Extending the notion to the core is simply a matter of implementing MPLS and/or DSCP. This is a well-understood problem, and none of it depends on “deep packet inspection.”
Companies pay Verio, Akamai and WebEx for low-latency QoS services over the Internet today and they're generally very happy with the results. Even between the US and China, WebEx delivers packets quickly and reliably.
QoS is perfectly practical and economical, and that's the reason Google is upset about it.
Someone sent me a comment that he can't post because of where he works.
One of the security arguments against neutrality is that the
government needs to be able to ship packets around quickly and
reliably in an emergency. If you give the major telcos packet
prioritization, they can make some packets flow more smoothly . . .
for a while. But the open ecology of the Internet is the biggest
driver of innovation and investment, and those paces will slow. How
many years will it take before “priority” service for the government's
national security needs will be slower and less reliable than
plain-old-IP service would have been on a neutral network?
Hmmm?
You'll be hard-pressed to find a network engineering analysis showing that priority flows on a packet network have higher latency than generic flows on a lower-bandwidth packet network.
The Internet is a packet-switched network, not a telegraph network.
Actually I have run both packet-switched and IP-based (as well as mixed) networks, with end nodes and users numbering in the tens of thousands. I've also discussed this very topic with researchers who work on MPLS/DSCP technology for telcos like AT&T, for example. The consense is pretty much this: prioritizing packets on the Internet as it currently is built will result in only a small margin of improvement. Fanatisies about how it will significanly improve network performnace are just that - fantasies.
While it won't degrade performance for tagged traffic, it also won't do very much to improve things. Again, this has to do the the hetrogenous nature of the Internet, as well as how IP routing itself works - different enough from how packet, cell, and voice based networks to make it inaccurate to draw accurate analogies by comparison.
If each and every entity running equipment on the global internet isn't setting up their prioritizations in a compatible way, improvements resulting from prioritizing traffic will almost certainly not amount to enough to adequately address security or emergency concerns as they were framed in the original reference. And, of course if any content provider actually pays for traffic prioritization thinking to get consistant measurable results, they'll find they've paid for remarkably little.
As for the deep packet inspection issue (although not particularily relevant), the deeper packets are inspected, the more likely that what little improvement actually prioritizing traffic has to offer will diminish even more.
None of this is to say that prioritizing traffic will result in nothing. It'll certainly slow non-prioritized traffic down. That's because its easier to degrade network performance than it is to improve it from an IP prioritization point of view. So, in the end, it'll just slow people down, and occasionly improve other traffic in an unreliable way. It might seem to actually work at times, but don't count on it in a pinch.
If people are looking to IP diffserv settings to address emergency needs, they're looking in the wrong place. The entire traffic prioritization play is an attempt to make it look as though more is being offered, when in fact no additional bandwith is being put into the setting - the only thing that will actually improve reliability in a consistant way. The one thing it will cost telcos hard dollars to do.
Hmm, you talked to some engineers and they told you that until MPLS and DiffServ are implemented throughout the entire Internet, nobody's performance will be improved by tagging packets for priority service, but others will be slowed down?
That's an interesting analysis, for sure. Perhaps you could find somebody willing to make it public, and you know, stand behind it; maybe they could even show some data, so it wouldn't be “my daddy says your daddy is a dummy.”
Intuitively, DiffServ reduces jitter at each hop in a stream. If a stream has it all hops, under load his jitter is dramatically reduced. If the stream crosses 15 hops, and only 10 observe DSCP but they all preserve the markings, then the stream still gets a measurable improvement under load.
There's no need for the routers managing a hop with low mean latency to observe DSCP, as the bandwidth will keep the queue size low.
There are commercial enterprises selling low-jitter service to commercial Internet customers today: Verio and WebEx are two I've used, and their customers are happy.
According to your anonymous engineers, that's impossible. Thanks, but I'll believe my lying eyes.
PS: The Internet is a packet-switched network.
Actually, I am someone who works with IP networks using MPLS and diffserv settings as part of my job, and has run large packet-switched networks as well. The Internet isn't really a 'packet-switched' network - it's a routed network. The two behave differently with respect to individual packet deley among other things. On an open, IP routed network, one cannot simpy 'turn on' MPLS and ultimately, diffserv, to uniformely improve performance (which will seem to work some of the time). The settings need to be compatible at each hop for consistant improvement (consistant is what's desired in an emergency, I would imagine). This works well in closed networks where one entity is in charge of all the equipment.
If, as referenced earlier, people are thinking to 'turn on' prioritization to make the Internet ready to handle emergency VOIP traffic, someone will have to enforce compatible settings throughout the vast majority of equipment running the Internet. A difference at any hop along the way can easily introduce jitter or any other kind of noticable performance degradation. That same hop can easily clog completely under enough load, although given that the Internet is a routed network, data will just get rerouted, albiet at a delay costly from the point of view of something like VOIP.
The debate, by the way, between routed and switched networks goes a back to before the time when TCP/IP 'won out' as the protocol of choice for running large public data networks like the Internet. Packet switching proponents cited just the advantages you point out - more predictable delivery of data packets, and hence, in the precence of a prioritization scheme, better performance with respect to data involved in analog-to-digital conversion such as video or audio. Packet switching still does serve parts of the Internet.
However, in those days, streaming D/A data over large public data networks was at its best a novelty, since there were already large networks in place to deliver analog contect like voice and video. And, for implementing the Internet, there simply were not any route algorytms in the packet-switched world up to the task. TCP/IP at least had BGP to handle connecting large autonomous entities like AT&T, Sprint, UUNET, and so forth without the need for constant manual monitoring and adjustments. So, while packet-switching was fine for closed networks (and still is), it wasen't as usefull for connecting those closed networks together. When I submit this comment, for example, portions of its journey will travel over some hops that are packet switched. But its the routing that will determine the principal expediency of its trip.
And, my point is that the idea that in a market where the telcos are looking to obtain lucrative contracts to prioritize traffic for their large customers, the likelihood of deploying Internet-wide quality of service (QOS) and having it work even close to how it would work in a closed setting is close to nil.
There is, however, a chance that the larger backbone providers might agree on differve (I'm mixing a number of terms like QOS, diffserve, DSCP, and MPLS all of which are the frameworks used to tag and prioritize traffic) settings for something like 911 calls. Even so, the impact of prioritization is not uniformely distributed throughout the path through the Internet - it sensitive to relative load, and much more senisitive at the ends of a path, rather than the middle hops. The middle hops are under predictable load, and the improvement from prioritizing traffic is also more predicable. At the point with more varible traffic loads, like your immediate upstream ISP, the prioritization settings will have uch more impact, and if they tag traffic at all differently than the backbone providers, representations made by the backbone providers for improvements will not be realistic or likely met.
This is just the way QOS (more at play on the ends) and diffserve (more at play in the middle) work. So, while the backbone providers might reach, and possiblly honor, some kind of quasi-compatible scheme for prioritizing, unless all 'last mile' ISPs are compatible as well, it won't matter as much what the backbone providers do. Compatiblility here is more significant than just the presence of prioritization tagging and queuing.
Yes, occasional improvement will work, but again, if a system is flooded with emergency VOIP calls and the local ISP isn't set up with enough raw bandwidth and compatible prioritization configurations (its unlikely that many are or will be as they have no financial incentive to do so), that traffic will experience real delays.
I bring this up not so much in the context of streaming entertainment and educational media over the Internet, but in the context of the delivery of emergency data. If the security/safely angle becomes predominent in the overall debate of 'net neutrality', it seems things will be very different. It could very well come down to some kind of federally enforced scheme for prioritizing traffic, to make sure everyone is tagging and treating traffic in a consistant way, for emergency needs. In and of itself, I don't see that as a uniformly bad thing.
That's a novel and I won't respond to all of it.
You say: If, as referenced earlier, people are thinking to 'turn on' prioritization to make the Internet ready to handle emergency VOIP traffic, someone will have to enforce compatible settings throughout the vast majority of equipment running the Internet.
Yes, that's the assumption.
This is an interesting direction for things to take, if in fact the 'safety' angle starts to become more prominent. Without some way of maintaining 'net neutrality', the government would be left to both build a set of standards for QOS/Diffserv and enforce them. Not a politically minded person, I would imagine the FCC could be tasked with the architecture and enforcement roles.
Just from a standards point of view, coming up with a comprehensive QOS design for the Internet, I would think, would be a nightmare for the telcos and other ISPs. Such a set of requirements would without doubt dwarf any legislation drafted to keep the Internet neutral. ISPs would very likely end up under a much larger set of government regulations than with net neutrality safeguards in place, if people start going down the safety argument path.
Of course, so much of the rest of the world's Internet traffic flows through the large backbone 'pipes' in the US, I can't imagine how other countries would feel about the FCC regulating their Internet traffic.
There yet another angle unexplored - that if in fact QOS/Diffserv settings are implemented, this is yet another avenue for mischief, since those protocols are not secured (very few TCP/IP protocols are secured), and are certainly vulnerable to misuse by anyone capable of manipulating those settings in their TCP/IP packets. I haven't really given it much thought, but I think it would be possible to take advantage of the fact that routers and switches are paying attention to QOS/Diffserv to accelerate DDOS traffic, for example.