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.