Revived Net Neutrality bill cripples Internet for real-time applications
Congressman John Conyers and Zoe Lofgren have reintroduced a Net Neutrality bill that prohibits charges for “prioritization or enhanced quality of service” in the name of stopping discrimination. Unfortunately, it stops a lot more than discrimination; it flat out bans tiered pricing for different levels of QoS (Quality of Service) which cripples the Internet under the justification of banning “discrimination”. Here’s the text of the bill from the first time this bill was introduced that Richard Bennett dug up.
“If a broadband network provider prioritizes or offers enhanced quality of service to data of a particular type, it must prioritize or offer enhanced quality of service to all data of that type (regardless of the origin or ownership of such data) without imposing a surcharge or other consideration for such prioritization or enhanced quality of service.”
Why force the bundling of QoS or elimination of QoS?
This revived bill means that QoS service must either be bundled in to the price of broadband even if some consumers don’t want it or it means QoS doesn’t get offered at all even if some people do want it. In either case, we have a travesty in the making with this revived Net Neutrality bill.
The reality is that some people only surf the Internet, download movies, send some emails and they don’t need enhanced QoS because QoS is all about providing low latency and consistency and not about increasing data throughput. Other people who use VoIP services like Skype, Vonage, Lingo (I am a customer), online First Person Shooter gaming, or video conferencing don’t care much for increased data throughput but they want lower latency and data consistency. If QoS is given to everyone because of government mandate, why should the first group of people who don’t care about low latency subsidize the second group of people? If QoS is not offered to anyone because of government mandate, why should the second group of people be denied the ability to buy enhanced QoS?
The meaning of “discrimination”
It seems strange that I have to define what the word “discrimination” means but I’m left with little choice given the fact that the word is being misused in this context of Net Neutrality. Discrimination in context of Internet services would be if an ISP created a pricing scheme that said that Whites can have an enhanced QoS service for $10/month but every other race of people must pay $20/month. If congress wants to ban this sort of discriminatory pricing, I would be all for it. But what the Conyers-Lofgren Net Neutrality bill says is that no one can pay ANYTHING in addition to the base price of Broadband services. That’s an outright ban on the sale of QoS which effectively eliminates QoS and cripples real-time applications on the Internet. This is not a ban on discrimination; it’s effectively a ban on progress on the Internet.
You can’t grow your way out of congestion
There are many in the Net Neutrality camp who claim that prioritization and network management wouldn’t be necessary if only we had a dumb fat pipe and that the need for QoS is a lie. The problem with the “dumb fat pipe” theory is that it has no basis in the world of science and engineering. In fact, the opposite has been proven because even the fastest broadband networks in the world like Japan are being slammed by peer-to-peer induced congestion.
Japan’s broadband infrastructure is around 10 times faster than US wired Internet infrastructure and probably has 10,000 times more capacity than US wireless Internet infrastructure. Japan’s broadband infrastructure can’t grow their way out of congestion yet Net Neutrality proponents argue that a mere quadrupling of capacity would eliminate the need for network management or prioritization entirely. This is a pipe dream and no amount of bandwidth will ever be enough because an infinite number of packets can be generated. Even a $100 up-converting DVD player can generate around 1.5 gigabits per second (1500 Mbps) and I could fill a gigabit broadband tomorrow if you gave it to me.
What is QoS and why is it critical?
Given the fact that we can never grow our way out of congestion, we must have the ability to prioritize packets to enhance the QoS. There is nothing insidious or evil about packet prioritization/QoS and it has nothing to do with increasing data throughput and the speed of file downloads as the Net Neutrality proponents want us to believe. Prioritization/QoS is merely a way of changing the order of delivery which is critical for real-time applications like VoIP, video conferencing, and some types of online gaming that rely on fast human reaction time. The fact that you improve the latency of a low-bandwidth application virtually has no effect on download services that favor higher throughput. Take the following example of a router transmission stream where “A” represents VoIP packets and “b” represents music download service packets.
The first critical lesson here is that the same number of “A” and “b” packets get transmitted in the same duration of time with or without QoS. That means the music download service represented by the “b” packets isn’t affected by QoS one way or another. But even if the “b” packets are slowed down a little, it doesn’t make much difference if a song is downloaded in 100 seconds or if it’s downloaded in 105 seconds.
The second lesson here is that prioritization doesn’t hurt or help download services because prioritization alters latency and not data throughput. Many Net Neutrality advocates misunderstand prioritization as a way of gaining an unfair advantage in video distribution but they’re fundamentally mistaken about the technology. The only thing that speeds up file and video distribution are content distribution servers that distribute the work load through a technology called “caching”. Nobody distributes content on a large global scale without the use of caching technologies because it’s insanely expensive and practically impossible. Nobody uses prioritization technology to deliver files and videos because it costs a ton of money with zero results.
The third critical lesson is that QoS makes all the difference in the world to the VoIP packets represented by the “A” symbol. In the first example without, you see large durations of time where “A” packets aren’t arriving in a reliable time interval shown by the black line markers. Those two VoIP “A” packets that don’t show up on time are simply discarded and the sound quality degrades making the person on the other end difficult or impossible to hear and understand. In the second example where real-time applications are prioritized, all the VoIP packets show up on time and the call quality is perfect.
Data comes out of a VoIP device in a smooth predictable manner but it can easily become garbled as it passes through an unmanaged and congested network where a few bandwidth hogs (typically peer-to-peer applications) can easily overwhelm the real-time applications. Without prioritization, bandwidth hogging applications can squeeze out real-time latency-sensitive applications. But with prioritization, we can have a state of harmony where bandwidth hogging applications aren’t affected but real-time applications are protected.
Unintended privacy consequences of Net Neutrality legislation
Some of these Net Neutrality bills make exceptions for emergency services but why should only emergency calls be reliable? Why shouldn’t the Internet provide circuit-switched reliability like the traditional telephone network? Why shouldn’t consumers get responsive gaming when they’re willing to pay for it?
The bigger problem is the issue of privacy. How do these legislatures think ISPs are going to identify an emergency 911 call? Are these bills suggesting that ISPs inspect beyond just the TCP headers that identify application type and snoop in to actual user data to figure out which telephone number consumers are dialing? What happens if VoIP implementations encrypts the user data and the network can’t identify the destination, does that mean no prioritization for that emergency call? What if the user doesn’t want their ISP to know when they’re dialing 911? These are some of the privacy and technical issues that have yet to be addressed.
Misrepresent the architecture of the Internet and the end-to-end principle
There’s a huge misunderstanding being propagated by Net Neutrality proponents like Larry Lessig and Susan Crawford that the Internet has always been dumb and it was built on the “end-to-end principle” (AKA “Net Neutrality” or “Network Neutrality”). They claim all intelligence must reside on the computer end-points and that the network itself must be dumb and devoid of intelligence. Lessig at the Stanford FCC hearing on broadband management in April 2008 stated that anyone proposing to change or deviate from this end-to-end principle must carry the burden of proof to justify changing the Internet.
The problem is that Lessig and Crawford do not understand what the actual end-to-end principle means and they are misusing it to further their own cause. One of the principle authors of the end-to-end principle (originally titled “end-to-end arguments”) is David D. Clark. Clark along with Marjory S. Blumenthal in 2000 wrote “Rethinking the design of the Internet: The end to end arguments vs. the brave new world” where they explain that:
“What is needed is a set of principles that interoperate with each otherÑsome built on the end to end model, and some on a new model of network-centered function. In evolving that set of principles, it is important to remember that, from the beginning, the end to end arguments revolved around requirements that could be implemented correctly at the end-points; if implementation inside the network is the only way to accomplish the requirement, then an end to end argument isn’t appropriate in the first place.”
The above quotation clearly debunks everything that Lessig and Crawford would have us believe about end-to-end and the architecture of the Internet. The Internet never strictly adhered to the end-to-end model. While the Internet may have heavily favored the end-to-end model in the beginning, it has steadily moved away from end-to-end towards a mixture of network-centric and end-to-end approaches based on the solution that best fit the requirements.
Larry Lessig is also wrong when he tells us that introducing prioritization or QoS to the Internet would be a change. That’s because enhanced QoS service contracts are already in use by business Internet customers and have been for some time. These legal and legitimate contracts would be outlawed by this latest Net Neutrality bill and those business customers would be prevented from buying a service that they need. The irony here is that Lessig is the one that’s actually pushing for a Government mandated change on the Internet to ban existing contracts and relationships yet Lessig was the one that argued that those who seek change must bear the burden of proof.
Misrepresenting the Net Neutrality debate as a first amendment issue
The dirty little secret of the “Net Neutrality” camp is that they never want to talk about what they’re actually trying to legislate which is the ban on perfectly legitimate tiered pricing models for enhanced QoS. They would rather misrepresent Net Neutrality as a civil rights movement that fights against unfair price discrimination and fights the blocking of websites. But I’m all for a ban against discriminatory pricing where different people or companies are charged different rates. I’m all for a ban against service blocking on the wired Internet and I’m all for a ban against the blocking of legal content websites. This is what a reasonable Net Neutrality bill would do but why ban tiered pricing on enhanced QoS? This is the question that Net Neutrality proponents can’t answer which is why they dodge it and misrepresent Net Neutrality as this fight for the “first amendment of the Internet”.
Even Tim Wu won’t stand up for Net Neutrality legislation
Tim Wu, a self proclaimed father of Net Neutrality, couldn’t run fast enough away from the issue of prioritization service banning at the Net Neutrality summit at University of San Francisco on a panel with me. Wu kept saying over and over again that he doesn’t care about the legislation and that it wasn’t important. Only when I pointed out his hypocrisy that he was on YouTube saying how the legislation was important did Wu admit he was for these anti-QoS bills. But Wu immediately stated that the legislation wasn’t important and that what was really important was the “spirit of Net Neutrality” and “how we feel about Net Neutrality”. So if the “father of Net Neutrality” says the legislation isn’t important and isn’t willing to defend it, will Mr. Conyers and Lofgren drop their revived bill?
Does the inventor of the web really support Net Neutrality?
Tim Berners-Lee (inventor of HTTP, the language of the World Wide Web) enthusiastically supports Net Neutrality but his own words contradict him. Here are two quotes from Tim Berners-Lee:
http://dig.csail.mit.edu/breadcrumbs/node/144
“Net Neutrality is NOT saying that one shouldn’t pay more money for high quality of service. We always have, and we always will.”http://dig.csail.mit.edu/breadcrumbs/node/132
“We pay for connection to the Net as though it were a cloud which magically delivers our packets. We may pay for a higher or a lower quality of service. We may pay for a service which has the characteristics of being good for video, or quality audio.”
It’s clear that Tim Berners-Lee is wrong when he says “Net Neutrality is NOT saying that one shouldn’t pay more money for high quality of service” because this is exactly what the Markey House 2006 amendment, Snowe-Dorgan Senate 2006 amendment, and now the latest Conyers-Lofgren Net Neutrality bill seeks to do. While Tim Berners-Lee has never specifically commented on any Net Neutrality bill, it is clear from Tim Berners-Lee’s words above that he would have to be against the latest Conyers-Lofgren Net Neutrality bill.
What do the fathers of the Internet think?
Bob Kahn calls “Net Neutrality” a slogan during an interview with him at the Computer History Museum. He also stated that he was “totally opposed to mandating that nothing interesting can happen inside the net. But that interesting stuff should be by consenting networks, not something that prohibits others.” This is more proof that Larry Lessig and Susan Crawford’s idea of what the Internet should be is completely out of touch with the founders of the Internet.
Vint Cerf says he’s for Net Neutrality and even praises Congressman Markey as someone who knowledgeable on Network Neutrality. But Vint Cerf has never publicly stated if he would actually back Congressman Markey’s 2006 bill which bans tiered pricing on enhanced QoS. I would challenge Vint Cerf to explain if he would support a ban against the sale of QoS or challenge anyone to produce a single documented quote from Vint Cerf saying he would support a ban on tiered pricing on QoS.
Conclusion
Net Neutrality, as it exists in the Conyers-Lofgren bill has little to do with protection against discrimination. It is an unnecessary set of regulations that bans the financial incentives to build networks that are hospitable to real-time applications and this will have severe consequences for the future of our Internet infrastructure. The future of the Internet deserves better than bumper-sticker slogans and misplaced fear-mongering on non-disputed civil rights issues. Let’s at least have a debate on the real issues on network architecture and prioritization. I would welcome any debate where network engineers argue why. Let’s see the Net Neutrality proponents produce a single argument or a single Internet architect who is for the banning of tiered pricing on prioritization/QoS.
FYI to the ‘George Ou’ readers who may have missed this ars technica article which gives you an ‘honorable mention’:
http://arstechnica.com/news.ars/post/20080327-one-technical-key-to-net-neutrality-solving-tcp-congestion.html
An aside: My VoIP SIP service provider is Gizmoproject (www.sipphone.com) who allow ‘bring-your-own-device, BYOD. Using Asterisk PBX 1.4 is beneficial in many respects. Calls are managed by the PBX attendant, with DID and SIP-to-SIP free and free long-distance calling capability. The rate for landline calls is modest. Small business owners will appreciate that Asterisk canl scale as their company grows and setting up additional toll-free IAX trunk lines incurs a modest monthly charge.
Asterisk manages both local and remote phone extensions–local being in the context of the subnet where the Asterisk is configured–remote being just about anywhere else reachable over TCP/IP.
An example of the remote extension might be across an IAX trunk line to another remote IAX Asterisk PBX server or simply to your cell phone. To Asterisk, when properly configured, picking up a phone in Tokyo or San Fransicso is transparent and one extension may see the other as belonging to a PBX region which exchange VoIP calls.
When on the road, if I switch over to remote, my Asterisk will answer incoming calls and ring my VoIP/SIP-enabled cell phone (Nokia N95) like any other extension on the PBX. Conversely, I can originate a call from my cell phone to any other extension on the PBX by its extension number using the SIP VoIP protocol. You’ll see more and more VoIP-ready cell phones coming to market.
In terms of QoS issues, Asterisk manages Jitter with it’s own Jitter buffer application,in addition to any end-point Jitter firmware that ATA/handsets may have. At home, an ‘unlocked’ linksys ATA 2102-NA) serves as another SIP phone extension (BYOD)–unlocked in that it isn’t provisioned and ‘locked’ by a service provider, e.g., Vonage.
More on Jitter here: http://www.voip-info.org/tiki-index.php?page=Asterisk+new+jitterbuffer
So, my thinking is that as much as can be accommodated, in terms of ‘net neutrality’ this is a prime example where technology and applications are being applied to endpoints to deal with QoS, thereby leaving the ‘pipe’ alone.
OK. Carry on.
In the past, I’ve heard many different sides the argument, but none as put together as nicely as by the telecommunications and traffic engineers themselves -
http://www.renesys.com/blog/2007/08/espn360reverse_net_neutrality.shtml
(Article) ESPN360 – Reverse Net Neutrality
To be honest, I see absolutely nothing wrong with best-effort policies, even including VoIP or Video-over-IP. If you are a hospital and you need radiology imaging — then keep it off the Internet. If you’re a content distributor of high-bandwidth content, then spend some money on R&D or continue using FLV (Flash video). Give people what they want, not what you think they need.
You said, "You can’t grow your way out of congestion
There are many in the Net Neutrality camp who claim that prioritization and network management wouldn’t be necessary if only we had a dumb fat pipe and that the need for QoS is a lie. The problem with the "dumb fat pipe" theory is that it has no basis in the world of science and engineering"
QoS is a lie.
Lower latency is tied to size of bandwidth (IP/ICMP/TCP/UDP RTT calculations anyone?? — that’s science as far as I’m concerned!). Consistency comes from quality engineering of architecture, hardware, and [especially] software. It doesn’t come from a router/access-device’s QoS feature set.
The problem with congestion exists — yes — but it is due to the software. The need for QoS arises because Cisco, Juniper, and the rest of the router and access-device vendors can’t get it together and provide a functional piece of software to move packets around the globe without any significant performance degradations. In fact, net-neutrality is more of an issue with the vendors than it is with the providers.
So providers do need QoS, even though it is a lie. How’s that for confusing the issue?
The basics come down to this: I don’t mind if my provider does what they need to do to keep their network running and my packets happy. Do I trust them? Hell no. Do I trust the government to regulate them? Hell no.
Do I want the government to regulate router/access-device vendors with strict guidelines on producing software that is capable of meeting the needs of providers and users? Maybe. I definitely want somebody to do something about it. I would prefer to see the vendors take on this liability and to stop producing shoddy products. Maybe a class-action lawsuit is in order from the providers on behalf of its users?
How do we push this liability on the router/access-device vendors? The more QoS features they add, the higher latency our packets get and the more congestion we see. It’s a catch-22.
I have to ask this question because I am honestly sick of this. The only politician running for president that has an understanding of his options and a presence on the internet would be Obama who wants to remove any QoS as well.
Perhaps some year there will be a candidate who would think about pushing technology forward instead of hindering it.
Excellent article, George. The folks who say that you should not be able to pay more for better or faster service do threaten the development of the Internet as a medium. Such limits also do not make sense from a business perspective. What if a small startup company wants to compete by offering UPS Red delivery rather than the usual UPS Ground, either as a promotion or for an additional fee? Would we want to prohibit that? Why do advocates of such restrictions make the bogus claim that only large companies would pay for expedited delivery?
http://arstechnica.com/news.ars/post/20080327-one-technical-key-to-net-neutrality-solving-tcp-congestion.html
Thanks Dietrich, that was sort of related to the issue of network management
"In terms of QoS issues, Asterisk manages Jitter with it’s own Jitter buffer application,in addition to any end-point Jitter firmware that ATA/handsets may have. …snip… So, my thinking is that as much as can be accommodated, in terms of ‘net neutrality’ this is a prime example where technology and applications are being applied to endpoints to deal with QoS, thereby leaving the ‘pipe’ alone."
No Dietrich, you cannot solve QoS on the end-points alone. Jitter buffers are pretty much standard in VoIP end-points but it doesn’t mean your voice quality doesn’t go down or get completely dropped. If you don’t believe me, fire up a BitTorrent client and let it go full throttle without any QoS on your router and see how well Asterisk works.
Even if you implement QoS on your own router for OUTBOUND traffic, that only solves half the problem. If your downstream VoIP traffic can’t be guaranteed in a timely manner, your call quality will suffer or drop out.
http://blogs.zdnet.com/Ou/?p=251
First of all Dre, the ESPN360 reverse net neutrality issue was first broken by me in 2006. The story you linked to on renesys and the other stuff they link to were written in 2007.
Dre says: "QoS is a lie.
Lower latency is tied to size of bandwidth (IP/ICMP/TCP/UDP RTT calculations anyone?? — that’s science as far as I’m concerned!). Consistency comes from quality engineering of architecture, hardware, and [especially] software. It doesn’t come from a router/access-device’s QoS feature set.
The problem with congestion exists — yes — but it is due to the software. The need for QoS arises because Cisco, Juniper, and the rest of the router and access-device vendors can’t get it together and provide a functional piece of software to move packets around the globe without any significant performance degradations."
Dre, you do not know what you’re talking about regarding QoS. If you’ve ever built a network that had to support voice and data, you wouldn’t make these ludicrous statements.
"I would prefer to see the vendors take on this liability and to stop producing shoddy products. Maybe a class-action lawsuit is in order from the providers on behalf of its users?"
And I would prefer you stop propagating meritless conspiracy theories and class action lawsuits and spend some time learning about network engineering or stick to topics you’re qualified to speak on.
"No Dietrich, you cannot solve QoS on the end-points alone. Jitter buffers are pretty much standard in VoIP end-points but it doesn’t mean your voice quality doesn’t go down or get completely dropped. If you don’t believe me, fire up a BitTorrent client and let it go full throttle without any QoS on your router and see how well Asterisk works."
Over RR cable I have ~10Mbps down/1Mbps up but I can see that it might be an issue over DSL.
Actually, the ‘preferred’ codec I have set is G711u but will fall back down to as low as G.729a which is a 8kbps audio protocol.
I have used bittorrent during phone calls and it’s been tolerable but not optimal.
Thanks George.
FYI, I’ve been dealing with a distributed SSH attack for the last several days.
http://seclists.org/incidents/2008/May/0000.html#start
I use DenyHosts with PermitRootLogin=no. I get system emails from DenyHosts and have incurred probably over 1,000 hack attempts.
Only this afternoon did it completely subside
I ran Zenmap on a range of ips returned by sshd and found most of them were Linux Apache servers presumably harnessed to run dictionary ssh scanners. The attacks were done in such a way to avoid the Denyhost pickup up 5 consequetive login attempts. Denyhosts would add the ip to /etc/deny.hosts file.
Since the ips kept changing and alternating, Denyhosts couldn’t put them into hosts.deny.
Finally it went silent this afternoon, you have any info about this George?
"Over RR cable I have ~10Mbps down/1Mbps up but I can see that it might be an issue over DSL."
Cable is even less reliable than DSL, you’re sharing 10 Mbps up with up to 400 people and the upstream protocol signaling mechanism can have collisions.
"Actually, the ‘preferred’ codec I have set is G711u but will fall back down to as low as G.729a which is a 8kbps audio protocol. "
8 Kbps is the payload for the codec. Add the packetization overhead and you’re up to 26 Kbps.
"I have used bittorrent during phone calls and it’s been tolerable but not optimal."
You’ve proven my point. It’s FAR from optimal in my experience and causes a LOT of dropout. Consumers and especially businesses should never have to tolerate that. Try using BitTorrent full blast and gaming at 600 ms ping and you’ll figure out why QoS is absolutely critical.
QoS is a service that I would pay money for in my broadband service. I would love to have a 100 Kbps quota for high-priority tagged packets and maybe it would let me save up a little priority and be able to do an hour of 300 Kbps priority when I’m using Video Skype or if I’m doing three simultaneous VoIP G.711 uncompressed phone calls at the same time. I would love to be able to get 40 Kbps of continuous upstream priority and 100 Kbps of continuous downstream priority for a 6 hour online shoot-em-up gaming fest. I’m sure a LOT of consumers would pay for a low-latency service and I’m sure a LOT of customers don’t require any low-latency services.
What offends me is that mega corporation Google wants to lobby the government to prohibit me from buying these services. Google is trying to cripple real-time applications on the Internet.
host said, "And I would prefer you stop propagating meritless conspiracy theories and class action lawsuits and spend some time learning about network engineering or stick to topics you’re qualified to speak on"
Did you really intend on saying this? I’ll have you know that I worked at Cisco in their professional services group as a CCIE for many years before working for other major Fortune 100 organizations in a networking engineering capacity. I attended and was outspoken at NANOG from 1996-2004. Network engineering is not a new topic for me. The last Cisco partner that I worked for did managed voice/network services for over 50 Fortune 500 companies. We supported thousands of CallManager/Unity/etc integrated voice/data networks — and I was the highest escalation point for both engineering/design and operations.
I never said that QoS is bad… we need it. Unfortunately, we need it for mostly the wrong reasons. It’s a necessary evil.
Also — there is no conspiracy theory behind it. The software sucks, and it causes latency. No one conspired to make the software crap — it just happened that way. Another problem is the network design and architecture is often limited in choices. Not everyone can afford or build a network that utilizes redundant Metro Ethernet (disparate paths and providers) to local data centers that support multiple carriers all acting in an IP transit or peering relationship. This sort of thing usually only can happen in certain parts of NYC, Chicago, Dallas, Atlanta, LA, Portland, Seattle, Denver, and the Bay area (at least in the US).
When you’re stuck with T1’s and frame-relay spaghetti, of course QoS is an important aspect of a corporate network. I thought we were talking about NSP networks anyways, right?
"I never said that QoS is bad… we need it. Unfortunately, we need it for mostly the wrong reasons. It’s a necessary evil. Also — there is no conspiracy theory behind it. The software sucks, and it causes latency."
Then why do you keep pitching these crazy theories? You accuse all the vendors of writing software that “suck” based on what? Why spout such nonsense?
The latency caused by software delay is low on a good connection. The problem is that latency builds up when there is congestion and you need QoS to prioritize your real-time applications. It’s not a "necessary evil"; it’s just plain necessary regardless of how much capacity and redundancy you throw at the problem.
Case in point. A USA coast-to-coast non congested link has a one-way delay of around 30-40 ms. Fill the link up to peak capacity and all of a suddent just your first-hop latency is 300 ms or higher which makes gaming impossible and VoIP becomes unreliable and low quality.
In your example, the problem would be due to lack of constrained (some say constraint) based routing, not QoS features.
The regular one-way delays introduced on links that are not fully congested are primarily due to software (not via accelerated hardware as many would have you believe i.e. ASIC/FGPA/specialized-processors). It’s either software or sunspots, and I’m not going to theorize on the latter.
Since you link to this blog in your blogroll, maybe you’ll consider their expertise on the matter -
http://erratasec.blogspot.com/2007/02/high-performance-security-appliances.html
No Dre, it’s QoS we need. All the ASICS in the world won’t solve the congestion problem without prioritization. The speed of light delay alone accounts for most of the latency on a non-congested network. The time it takes to convert light in to electricity and back to light multiple times across each hop also factors in. The software IS NOT the problem. It’s not the software causing 300-600 ms delay; it’s congestion that’s causing that and the only way you ensure quality of service is to implement prioritization. Having an all ASIC based router isn’t going to fix the problem. Throwing more bandwidth at the problem isn’t going to fix the problem because users will fill up whatever you give them.
What I vehemently disagree with is your suggestion that the entire industry ought to be served with class action lawsuits based on your unsubstantiated and ridiculous claims.
As for your attempt to quote Robert Graham at erratasec on an unrelated post, I know Robert and I can tell you for a fact that he doesn’t agree with you on QoS and Net Neutrality.
You said, "No Dre, it’s QoS we need. All the ASICS in the world won’t solve the congestion problem without prioritization"
Ok. I agree with this. Do you understand the difference between constrained-based routing and QoS features such as prioritization?
You also said, "The speed of light delay alone accounts for most of the latency on a non-congested network".
No, the speed of light delay accounts of SOME of the latency on a non-congested network. Most of the delay comes from software "life-of-a-packet" scenarios. Ask Robert Graham about that.
You blurbed on about, "The time it takes to convert light in to electricity and back to light multiple times across each hop also factors in. The software IS NOT the problem"
Do the calculations yourself.
You additionally said, "It’s not the software causing 300-600 ms delay; it’s congestion that’s causing that and the only way you ensure quality of service is to implement prioritization. Having an all ASIC based router isn’t going to fix the problem. Throwing more bandwidth at the problem isn’t going to fix the problem because users will fill up whatever you give them"
Having an ASIC based router WILL NOT fix the problem. So we agree. When did you see that I said that ASCI-based routers would help?
Throwing more bandwidth at the problem with help if you use constrained-based routing EXCEPT during peak traffic.
You went on to add, "What I vehemently disagree with is your suggestion that the entire industry ought to be served with class action lawsuits based on your unsubstantiated and ridiculous claims".
Well that’s nice, but it’s the vendors faults. If not lawsuits today or in the next five years — expect more and more regulations. Does the FDA keep you healthy and happy?
Look, I’m not some libertarian prick. For all you know — my political agenda could be neo-convervatist or complete socialist. I don’t care about any of that, and I don’t understand how it affects this particular issue. It seems at any moment, you’re about to bust out with some ad-hominem attacks against me (if you already haven’t). Please just chilll out and realize that it is the software and lack of MPLS TE that is causing the problems with congestion — and yes, I agree with you that QoS is also a solution to the problem… unfortunately it’s not the only solution.
Regulation will prevent MPLS TE improvements and other things like it to NEVER happen if QoS is locked into the law books. Regulation about QoS will also damage the potential of the network equipment vendors, who are failing to provide new solutions for performance problems by keeping their quality control (i.e. validation of user needs/requirements) at the marketing/"do-everything" level and not in the best-interest of their customers. The best-interest of their customers would be to solve the performance problems at the root-cause — not with band-aids such as QoS.
Lastly, you said, "As for your attempt to quote Robert Graham at erratasec on an unrelated post, I know Robert and I can tell you for a fact that he doesn’t agree with you on QoS and Net Neutrality"
I fail to see how the software "life-of-a-packet" is unrelated to my argument. It may be unrelated to your arguments, but it would be nice if my voice could also supply external references. It would also be nice if you read them and try to interpret the meaning behind it.
You keep saying QoS is a “necessary evil” caused by bad software. You keep saying class action lawsuits are needed against vendors. You keep saying more regulations are needed. You’re not making any sense and you’re just plain wrong.
Another thing I forgot to mention is that OEO conversions and other optical network infrastructure and architecture also adds fuel to the problem of latency and/or packet loss (e.g. amplifiers, et al).
Especially continuous and unnecessary OEO conversions and pushing it into software as done by something like a Packet-over-SONET interface.
I don’t think "All optical" routing solves the problem of latency, but it certainly doesn’t hurt it.
Best yet would be to combined constrained based routing at the optical layer. Adding intelligence to the network may help more than adding bandwidth or QoS ever will.
"You keep saying QoS is a "necessary evil" caused by bad software"
QoS is one solution. It’s not the only solution.
"You keep saying class action lawsuits are needed against vendors"
Software produced by vendors is built to make them money, not to fix bugs that benefit customers. The DDTS rate has to match adding features for marketing and Cisco won’t fix a bug unless customers complain about it / report it. If Cisco finds bugs in the SDLC, they don’t fix the critical ones before release on purpose (and what they consider critical based on their prioritization is also off kilter). They never release builds/trains that have the features loaded/modularity needed by/for a specific customer. Each released image has everything except the symbol tables. Juniper Networks, Foundry Networks, Extreme Networks, et al — they all follow the Cisco party line.
It’s a goddamn racket, and people don’t even realize it. Let’s talk about the security of their products and then talk about whether or not class-action lawsuits are appropriate.
Also — being realistic — I don’t actually think class-action lawsuits are going to happen. You don’t seem to understand that I’m NOT taking sides on this issue or any issue — I’m simply speculating what COULD and WILL happen based on what HAS happened in other industries with similar problems throughout history. What other alternatives are there? What else can happen?
"You keep saying more regulations are needed"
Huh? I’m not saying anything about what is "needed"… I’m just speculating on what is happening and what I see. I honestly personally don’t think that more regulations are needed. These are all straw-man arguments. I’m not trying to get a reaction out of you. I’m speculating to try and understand the problem better. Nobody has the real answers — that’s why this is a debate and that’s why these problems aren’t solved yet!
"No, the speed of light delay accounts of SOME of the latency on a non-congested network. Most of the delay comes from software "life-of-a-packet" scenarios."
Speed of light latency accounts for at least 20 ms one-way latency from San Francisco to New York. Overall one-way latency from SF to NY is typically 35 ms one-way. 20 is most of 35.
Speed-of-light delay is the biggest insurmountable problem for Satellite
http://blogs.zdnet.com/Ou/?p=1022
Ok so show me a 70ms TCP RTT throughput test from SF to NYC from an IP transit router at Equinix to say an IP transit router at NYIIX. Please be sure to note best-exit BGP policy dictates the requirement of traveling through at least two networks — so be sure to that the IP transit routers aren’t owned by the same NSP.
70ms? I would say more like 82ms. Thus the OWD is 41ms, and if speed-of-light is 20ms, then the software life-of-a-packet is causing more — 21 ms. Are we done now?
Plus, in your example… what’s causing the additional 15ms of latency? What is it? Hint: it’s not congestion!
There are coast to coast connections that are 35 ms one way if there are few enough hops (straighter path and less equipment to go through). 20ms is the bare minimum speed of light delay and that’s assuming a fairly straight path which is never the case in the real-world.
"Plus, in your example… what’s causing the additional 15ms of latency? What is it? Hint: it’s not congestion!"
Lets for the sake of argument say you’re right and that it’s 21ms delay added by a lack of an ASIC (I doubt that). 20 ms additional latency isn’t a problem. We’re talking at least 10 router hops here (excluding layer 2 switching equipment) so each router might AT MOST tack on 2 ms of delay. Besides, just the packetization delay in the CODEC is 20+ ms. What we’re really worried about is congestion-induced delay which can be shoot up in to the 600 ms range or beyond if the congestion is bad enough.
Furthermore, just putting a 50% load on my broadband link raises my latency by 30 ms and by the time I get to 90% traffic loads my one-way latency shoots up 300 ms. This 30-300 ms delay per congested hop is what REALLY hurts, not this 2 ms per-router delay added because of the lack of an ASIC. Adding an ASIC and optimizing the software will at most reduce latency by 2 ms per router but it won’t do anything for that 30-300 ms latency added by congestion. The only thing that gets rid of that 30-300 ms congestion latency is packet scheduling prioritization technology.
The market has determined that it does not want to pay any more money for lower software latency because the return on investment is non-existent. It simply costs too much for too little gain. For you to act like you know better than the market and say that the hardware vendors deserve a class action lawsuit because they’re responding to the market is really obnoxious and offensive to me. Your logic and understanding is severely flawed.
"20ms is the bare minimum speed of light delay and that’s assuming a fairly straight path which is never the case in the real-world"
Why isn’t it the case in the real world? Could it have to do with software?
"Lets for the sake of argument say you’re right and that it’s 21ms delay added by a lack of an ASIC (I doubt that)"
Ok. I’m not pro-ASIC. Never have been; never will be. Where did you get this from? My theories may be crazy, but at least I’m not putting words into your mouth!
"each router might AT MOST tack on 2 ms of delay"
Why do routers have to tack on delay?
"What we’re really worried about is congestion-induced delay which can be shoot up in to the 600 ms range or beyond if the congestion is bad enough"
Which is why MPLE TE or some other form of constrained based routing would be a "nice to have" in addition to (or to replace) QoS prioritization.
"Furthermore, just putting a 50% load on my broadband link raises my latency by 30 ms and by the time I get to 90% traffic loads my one-way latency shoots up 300 ms"
Sounds like a speed-of-light problem. How far is the CO from your house?
"The market has determined that it does not want to pay any more money for lower software latency because the return on investment is non-existent. It simply costs too much for too little gain"
I don’t work for Alcatel or Timetra, but they don’t seem to have figured ROI on making a few low-latency devices that have been running in networks for over 4 years.
"For you to act like you know better than the market and say that the hardware vendors deserve a class action lawsuit because they’re responding to the market is really obnoxious and offensive to me. Your logic and understanding is severely flawed"
Not because they are responding to the market. Because they didn’t verify their software against performance bugs and they didn’t validate their software to user requirements outside of the market pressure. I’m not sure that they deserve it or that the class-action would win, but I am saying that it would probably open up some eyes and make people more accountable. Or would you rather have government regulations do this? Whether we like it or not — someone is going to have to give up some "privileges" that they think they are "rights".
Again, instead of arguing about it — I would rather that you speculate with me. Net Neutrality is never going to die — it’s always going to be an issue or else something else like it. You should know that my opinion is that I am against the regulations and for QoS and tiered pricing of bandwidth. However, my opinions don’t stop any lawmakers. Instead of standing my ground in blind faith, I’d rather make sure my world is in order if I plan on standing behind these opinions for any length of time.
Anyway you look at it, something has got to give. In history, typically lawsuits and regulations settle these matters of arbitration. Can you think of other ways to settle matters as great as this one? BTW I’m looking for solutions and stories — not a list of more problems.
My logic and my understand of these issues are not set in stone like yours are. I allow myself to grow to understand what mediation will look like. I can’t predict the future, but that doesn’t stop me from trying.
I wish you were just looking for solutions, but you’re drawing outrageous conclusions based on your ignorance. All equipment adds delay and it’s only a question of how much. Layer 3 devices typically add about 1 ms and switches are much lower in the sub 1ms range. That’s not a bug much less a class-action worthy flaw.
As I told you, just the packetization delay of waiting 1/50th of a second for 50 packets per second equals 20ms. There’s nothing you can do about that unless you go down to 100 packets per second but 50 PPS already adds a huge amount of overhead so VoIP engineers accept 20ms of latency as a reasonable tradeoff for adding ~18 Kbps of packet header overhead and they’re not willing to go to 36 Kbps of packet overhead.
1ms or even 2ms added per non-congested router is very acceptable as far as VoIP engineers are concerned. Their biggest problem is congestion-induced delay which rises from 0ms to 600ms on a curve depending on percent utilization on the link. Router-induced delay doesn’t even register on the radar as a problem in the context of packetization and codec delay much less in comparison to congestion-induced delay. You’re obsessing over a problem that’s one to two orders of magnitude smaller than packetization- and congestion-induced latency. Only a fool would consider the 1ms latency of a router to be a problem worth discussion. You might as well be advocating lawsuits against any computer that can’t perform 500 GB/sec of encryption with less than 10% CPU utilization.
They only way you can solve the biggest cause of latency is to deal with the congestion problem. This is done with priority scheduling where you’re rearranging the order of packets so that latency-sensitive applications can pass through a congested link almost as if there were no other traffic on the link.
"I would rather that you speculate with me."
No Dre. I don’t speculate; you do. I state facts. People like you are reckless and dangerous because you know enough to sound plausible to the untrained eye. That means people like you who aren’t qualified to speak on these matters can influence policy. People tend to want to believe that corporations are fundamentally dangerous and when they hear a half-ass plausible sounding theory from people like you, they want to believe it. They want to "stick it to the man" with lawsuits and you’re basically coming on my website trying to incite riot and legal thugery. My job is to thoroughly debunk the kind of nonsense that people like you spew.
Telling you to drop this nonsense is like trying to explain to you that the world isn’t flat. Now I wouldn’t even get so annoyed if you were merely asking an honest question, but you’re trying to incite a legal riot based on your ignorance. You don’t know what you’re talking about yet you arrogantly go around acting like an expert. My patience with you is gone. I’d love to stick around and debate but I just don’t have an infinite amount of time to clean up the intellectual manure you leave on my forums. So unless you’ve got PROOF of something worth advocating lawsuits over, do not come on my forums and advocating the equivalence of ambulance chasing. I don’t believe in censorship of reasonable content or people criticizing my view, but I’m not going to allow people to come on my forums pushing theories that are the equivalent of saying that the US government brought down the towers.
There we have the matter settled.
If you’re not pro-lawsuits — then you’re pro-regulations. Unless you have a better idea.
Also, it appears that you cannot have a normal conversation without getting too emotionally involved. If my views are based on writers such as David Rice (who wrote GEEKONOMICS and is qualified to speak, and has your so-called proof) — I can stand by these opinions above someone with your qualifications and abusive ad hominem attacks.
Get a grip and realize that you are pro-regulation. You would vote for the forced use of QoS Prioritization (assuming that we could vote on these matters).
QoS Prioritization is based on the concepts of DiffServ and Deep Packet Inspection. These would be the Internet’s undoing.
My recommendation is to also use QoS, but I don’t want it regulated. My QoS is not Prioritization alone, and it’s not Deep Packet Inspection (which does wonders on encrypted traffic, Mr. Security Expert).
My QoS is RSVP TE on MPLS LSP’s (IntServ instead of DiffServ). It involves adding intelligence to the network, avoiding packetization delay by using "all optical", and routing around congestion problems with constrained based routing. I prefer this to QoS Prioritization, but in theory you can have both and eat your cake, too.
Because you don’t understand IntServ and because you don’t know what "all optical" is… we don’t have an argument. You are less knowledgeable than me about this because you don’t know and haven’t built an NSP network. I went through WANDL MPLS TE training after building IP+ATM networks for years, including with Cisco PS. Your experience is with your home broadband link, which "often rises to 300ms latency when capacity is at 90%".
You INVITED conversation between network engineers — but you’re not one. You don’t know anything about BGP-4+, MPLS, QoS, or the internals of a router operating system or life-of-a-packet. Before we started this argument, you thought that the speed-of-light and packetization were the only elements that increase latency (and this packetization thing is new, btw).
So here is my legal riot to who will listen. My voice be heard, I can now rest this argument in peace. We can agree to disagree. I have no ill will towards you and hopefully we can have more meaningful conversations like this in the future.
Also — I’m not saying that the US government is responsible for causing congestion on the Internet. I already explained that there is no conspiracy — it just happened this way out of regular greed and placing marketing goals above customer analytics (by the router vendors).
Where is your proof that what I’m saying is not true? Where is your proof that QoS prioritization along with tiered pricing is the best solution to the problem of congestion on the Internet? The other thing that you forget — is that we AGREE.
Unfortunately, you think everything in the world is free and without a price. You think Congress and others will bow to your theories. They will not. Net Neutrality will go on. My suggestion is that we get our ducks lined up and show Congress that we’ve all been doing the right things. Cisco and others might be able to clean a little house, and NSP networks can work with router vendors such as Alcatel/Timetra on short-term solutions that implement constrained based routing along with QoS prioritization and a tiered pricing structure based around performance auditing. In other words — the books at least are clean. Remember GX? Remember Enron? What if somebody is hiding something in the router vendor camp or in the NSP camp? The only way to know is to open it up and investigate the source of the problems. You can do so with regulations — or you can do it with lawsuits. There are very few others ways.
Suggestion: I’ve had others that I know personally read our conversation in order to get peer review around my ideas.
Many say that they don’t know what is right. Others disagree with me (but they don’t agree with you).
All of them think that your arguments and points are much more out-of-line and biased than mine. They say things like "Who does this guy think he is?" when referring to you. They think this is largely because you feel a sense of ownership around this blog/forum you’ve created.
I did not intend to overstep my welcome here. I did not intend to get into an argument with you. I apologize for any misdirected, possibly inappropriate, language or behavior. I would appreciate it if you would help me understand why you are so convinced of my ignorance and conniving nature (as you would have it with the words you’ve written so far). Others are not convinced, although it helps that they do already know me.
So my suggestion is that you peer review your own language and ideas. Let me know what your friends and peers think about what we’ve written. If this is just you vs. me — we will fail to go anywhere with this.
Also — if you do have people who agree with you, I’d prefer that you cite them. I have listed several people who will back some of these theories as references, and will happily provide URL’s to the work if you can’t Google it easily.
Here go argue with this guy
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9085519
(Article) Opinion: A surfeit of network-neutrality legislation
"If you’re not pro-lawsuits — then you’re pro-regulations. Unless you have a better idea."
Dre, do not put words in my mouth. This is where you’re stepping out of line. You’re the one that is pro-lawsuit or pro-regulations because your brain lacks basic logic.
You’ve hooked on to this whacked theory that routers are inefficient and they’re adding 1 ms of latency to traffic. You believe this is such a huge problem that there needs to be lawsuits OR net neutrality regulation. You initially stated that this would negate the need for QoS. What you refuse to see or acknowledge is that this "problem" is one to two orders of magnitude smaller than packetization delay or congestion-induced delay. What planet are you on?
Dre: "Because you don’t understand IntServ and because you don’t know what "all optical" is… we don’t have an argument. You are less knowledgeable than me about this because you don’t know and haven’t built an NSP network. I went through WANDL MPLS TE training after building IP+ATM networks for years, including with Cisco PS. Your experience is with your home broadband link, which "often rises to 300ms latency when capacity is at 90%"."
Alright, that’s it. I built IP networks for large enterprise networks. You either clean your mouth up or get off my site. I don’t have time to argue with someone who doesn’t even understant that 1<20<300 and I’m not going to sit here and let you insult me.
I am pro-reality. Something has to give. Look, buddy, I’m straight up telling you that something has to happen and that something WILL happen. What is the worst of two evils? If you had to pick one: lawsuits or regulations, which one would you chose? I submit that the theory that lawsuits (or at least talk about them) is better than regulations on any side of the Net Neutrality or Anti-Net Neutrality arguments.
So I’m supposed to sit here while you insult me? I think you’re great at large Enterprise networks if that’s what you do; you clearly have a lot of expertise. But large enterprise networks are not NSP networks. Your expertise is not equivalent to my expertise.
It may be 1<20<300 today, but if router vendors and NSP’s are forced to add deep packet inspection and QoS prioritization features of the DiffServ variety WITHOUT also using bandwidth increases and MPLS Traffic Engineering aka RSVP TE of the IntServ variety then there is NO WAY you or anybody is going to solve the congestion problems.
Pretend that in 7 years 99% of the Internet traffic is SSL all demultiplexed to port 443.
Explain how deep packet inspection and QoS prioritization will help in that scenario. Please submit this in writing in the form of 4 paragraphs or more sans insults, due in this commentary ASAP.
QoS has NOTHING to do with deep-packet-inspection, encryption, or the protocol. The customer gets a percentage of traffic that they get to label as priority packets and the customer decides which packets they want to label regardless of protocol. The ISP that sold the service doesn’t care what protocol you’re running and they don’t need to buy expensive DPI appliances. They only need to make sure that you don’t exceed the quota of priority-marked packets that you purchased.
Your question about the SSL scenario tells me you do not even understand the most basic principle of how QoS works. If you did, you wouldn’t ask such a question.
BTW, I’ve run enterprise networks that utilized MPLS WAN connections that had QoS prioritization contracts in place. The customer paid for the service to prioritize a certain percentage of their traffic.
And so that works between providers… how???
The congestion is often between providers at peering points!
Utilizing MPLS WAN is different than running MPLS TE on a provider backbone.
1. Sounds like a mis-quote. I never said those things. You brought up packetization after the fact. The 1ms argument was about the speed-of-light vs. software-induced latency, which I still contend is true. If you go beyond just the SF to NYC example, and look at AUS to SF or similar, and the point drives home even further.
2. Another mis-quote/misunderstanding. I understand QoS. Let’s say that all of my SSL packets existing my infrastructure to my premium-paid MPLS WAN connection from ProviderA appear the same. How do I classify them? Which ones do I give priority to?
How would this work in an IP transit relationship? Pretend that instead of an Enterprise, that I’m ProviderB in an IP transit relationship with ProviderA (i.e. I pay them), which is not an uncommon scenario. Let’s say that I’m an IP transit provider myself, with my own paid customers. How do I (and I know QPPB is one answer to this, but that’s besides the point) send my untaggable SSL packets from CustomersC-Z to ProviderA and pass the tags on? How will I know that ProviderA will respect these tags? Also assume that the link between ProviderA is purposefully congested or under-provisioned by them in order to make my life more difficult with my customers.
Additionally, your logic assumes that we’re going to change economic models for how bandwidth is sold and purchased. This problem might work for niche services such as MPLS WAN, but it doesn’t work for IP transit and peering relationships for transit-AS’s (typically which are NSP’s).
You haven’t answered anything. Don’t post on this thread any more. You’ve had enough theads to talk here and I’ve given you plenty of chances to speak on this matter. This thread is now closed to you. You have demonstrated that you do not know what you’re talking about and you’re done on this matter.
No one wonders why you left ZDNet after reading this thread…
I’m sure that you couldn’t hang with Nate McFeters or Larry Dignan. How do you feel about your replacement, Dancho Danchev? I bet that’s got to hurt.
Wow… since you’re not really a journalist anymore… I have to wonder… what kind of "expert" are you?
Don’t need people like you around here.
Answer the following specific questions
1. How does 1ms router latency compare to 20ms packetization latency or 300ms congestion-induced latency? And how does that 1ms of latency in the router negate the need to deal with congestion-induced latency using packet scheculing prioritization technology? How does that justify a lawsuit against every router manufacturer as you suggest?
2. How do you explain the fact that you do not understand that QoS works regardless of protocol or encryption usage?
Don’t post another comment until you’ve answered these questions.
I know, this is twenty days after the fact, but I just spent an hour trying to follow the above discussion (heavily leaning on Wikipedia) and, if Mr Ou is still reading, I was wondering if you might answer a couple questions for me, a confused CS student (never built a network in my life, barely know the packet vs. datagram distinction, get most of my tech knowledge from Slashdot… so, basically, no credentials to speak of):
If I read this conversation right, if you have an uncongested coast-to-coast link in the USA with, say, ten hops in the link, you will likely have ping around 80 ms and one-way delay of half that, or 40 ms. (This is using the figures you and dre argued over above, but I checked it with traceroute during non-peak hours and it seems to be about right, maybe a little low.) Am I correct in thinking that that 40 ms OWD is because of:
-20 ms speed-of-light delay
-insignificant (<1 ms in most scenarios) router delay (combining the delays from all ten hops)
-and 20+ ms packetization/depacketization delay?
If that’s correct, then *could* packetization be sped up by making changes at the software level, or is TCP (which I believe is the upper layer protocol we’d be using here) pretty much going to packetize at the same speed (thus giving you the same latency) no matter how you send it data?
Lastly, my understanding of the most recent net neutrality legislation that I’ve looked at (Snowe-Dorgen 2007) was that it would only ban special QoS deals between networks and specific content providers–the law would prevent a scenario in which, say, Lingo data would have a higher priority than all other VoIP traffic because Lingo would have coughed up the big bucks to the ISP’s and Vonage wouldn’t have–while still allowing protocol-based QoS. Am I missing something here? Did the 2008 proposed act change this? If not, how does a ban on that very specific type of QoS impact the entirely reasonable protocol-based packet prioritization you proposed in this article?
I know those questions probably have quite a few errors just in the asking. Sorry. Thanks for any answer you may (or may not) give.
-W.
Each router adds roughly 1ms to the speed-of-light propagation delay. The layer 2 stuff (switches, DSLAMS, modems, etc) because they’re working on a lower layer that doesn’t need to deal with routing so they’re fundamentally faster. But again, we’re talking roughly 1ms delay which is insignificant. You might be able to lower that a little with faster ASIC hardware but do you honestly believe it will go to zero?
Even if it’s 15 routers and you can slash that to 8 ms delay (I doubt that much), what’s the point of gaining 7ms? It’s far less than the 20ms or 30ms of packetization delay you get in the creation of that VoIP or gaming packet. The real problem that you need to tackle is that transmit queue in the DSLAM that is opposite your DSL modem that might be 200 packets deep with up to a 1000 ms delay or more typically 200 ms delay.
So *CAN* you reduce software latency? Sure. Is it even remotely worth implementing? Not even close. The fact of the matter is; any function that is computationally expensive on existing commercial Cisco routers are already done with ASICs and you’d be hard pressed to lower the latency crossing a router any more than it already is.
Is the "problem" worthy of a civil class action lawsuit? That’s like saying that you get to sue Intel for selling you a $50 CPU that can’t encode 1080P H.264 in real-time.
As for Snowe-Dorgan from 2006, here is the exact language.
Snowe-Dorgan proposal:
(5) only prioritize content, applications, or services accessed by a user that is made available via the Internet within the network of such broadband service provider based on the type of content, applications, or services and the level of service purchased by the user, without charge for such prioritization;
So again, it says nothing about "special QoS deals"; it just flat out bans the sale of QoS. So if you as the consumer want to buy a service where you get to tell your ISP that you want to prioritize Lingo (which I am a customer of), Snowe-Dorgan 2006 and Markey-2006 would prohibit you from doing so.
You’ve shed a little bit of light on an often-intimidating world for me. Thank you very much, sir.
One more thing Wowbagger, a lot of these “experts” talk about ATM QoS without realizing that it doesn’t apply to the IP world. While ATM was designed with great QoS technology, ATM QoS works within the context of ATM and it does not work in the context of running IP over ATM. Multiple ATM cells make up a single IP packet and you can’t just go reshuffling ATM packets to see an effect on IP flows. You need to intelligently shuffle the IP packets either at the network end or you try to engineer the application to spit out an even flow of periodic traffic. So it’s foolish for these self-proclaimed experts like Dre to say that you simply need to switch to ATM technology because it doesn’t even apply here.
From what I’ve read on NN legislation, it applies more to preventing companies from paying to have their data load faster than their competitors data, and has no affect on customer service or pricing to the consumer. The text from the bill at the top even says that if you prioritize certain data, all data of that type must be prioritized. This wouldn’t prevent Comcast from having tiered pricing for consumers. Nor would it prevent them from prioritizing VoIP packets. Rather, it would prevent them from prioritizing Skype over Skype’s competitors, as THAT would be discrimination.
This whole article seems to misunderstand the intent of NN.
Are you doing selective reading? No, I did not misunderstand it. I want to be able to tell my ISP to prioritize only my IPTV stream when I order my IPTV service because I want it to work. I might want my ISP to only prioritize VoIP streams coming from Vonage or Lingo because I am customers of those services or just prioritize VoIP streams from anywhere. I might want my ISP to prioritize video on demand from Apple over Microsoft or vice versa. That is NOT discrimination, that’s consumer choice and they have a right to purchase this service if they want to. The Government shouldn’t step in and say you can’t buy this service and that this service has to be bundled in to the price of everyone’s broadband service.
Now if Apple paid AT&T money to block Microsoft video downloads or vice versa, that certainly should be illegal and already is illegal under anti-trust law. But if Apple merely paid AT&T for caching services for faster and more reliable delivery, that’s normal CDN (caching services) and there’s nothing strange or illegal about that. Any content distributor on a large scale pretty much has to buy CDN to get their content delivered anyways. That is how the Internet works today.