How ISPs May Quietly Kill VoIP

ravenII writes "PBS's i'Cringley's informative piece gives an eye-opening look at the anticompetitive behavior of some ISPs who are showing up late to the VoIP game. This is not something that could be easily mandated, and the beauty of this approach is that they're not explicitly doing anything to the 3rd party service applications. They're just identifying and tagging their own services, which is within their rights."

Comments

Re:Verizon

[Paska]

Read the damn article, this is different to the case you mention. They are not blocking access to other VoIP providers. However they are tagging (or will?) be tagging their own VoIP traffic which will force all other VoIP provider's traffic to run as non-guaranteed traffic and thus, could lead to dropouts or all round crap service.

Re:Encryption is the simple answer...

[m0rningstar]

No, it won't. You just de-prioritise ANY traffic other than your VoIP traffic.

And without some form of prioritisation across a public network, VoIP becomes a flaky proposition at best. You have a 250ms round trip latency budget, and encryption adds to the serialisation delay on both ends and impacts this. Plus any out of order packet delivery or jitter will further impact voice quality, along with compression.

And people expect their phone to work. All the time. Early adopters will tolerate the impact, but the money is in the commoditisation of the service and deploying it to everyone -- and everyone will not be willing to deal with a flakey phone.

That makes it worse...

[katharsis83]

Actually, adding on another layer of encryption makes the problem worse. From the article summary:

"...the beauty of this approach is that they're not explicitly doing anything to the 3rd party service applications. They're just identifying and tagging their own services, which is within their rights."

The service providers are prioritizing THEIR VoIP traffic; so unless you can encrypt and then mask your VoIP service provider's packets to look like the ISP's, all encryption will do is increase the latency for voice - remember encryption/decryption requires time. The ISP doesn't explicitily delay Vonage's packets, for example, it simply upgrades the QoS priority of their own packets; this conveniently screws over 3rd-party providers like Vonage while not getting the ISP's in legal hot water.

Encryption can protect your 3rd party call from evesdropping, but can only increase latency under this new sneaky scheme.

Re:Tag your own packets?

[The Vulture]

Well, you've got the idea correct, but it has nothing to do with how DSL can run aside POTS. DSL can run along POTS because one uses the low frequencies, and the other uses the high frequencies. If you have DSL on your phone line, and don't have the filter, you'll likely hear a hissing, that's the DSL signal.

However, should you get a combination cable modem/MTA (the VoIP box) from you cable operator (i.e. Comcast), it works like this:
* The DOCSIS 1.1 specification calls for a nifty little feature called "service flows". Service flows have their own QoS, and can be triggered by a variety of criteria, including TCP/UDP port numbers, Ethernet frame type, etc.
* From there, the cable operators will provision two (or more) service flows for the cable modem. One would be for the voice, which would receive the highest priority possible (but with a lower bandwidth), and the other one(s) would be best-effort, with a higher bandwidth allowed.

Cable operators can also use this to throttle any arbitrary connection (i.e. P2P), and in fact, have done so in the past, I would imagine.

A "side effect" of this would be that Vonage boxes would considered as best-effort, simply because they don't get classified into the voice flow by the software of the modem. This is because they won't meet the characteristics of the voice flow.

-- Joe

Re:This indeed disproves the myth of capitalism

[Anonymous Coward]

you're thinking of "chaos" not "anarchy"... do some reading.

*Cringely's* not being fair - or accurate

[billstewart]

Yes, there are some ISPs that want to kill every application that generates upstream traffic, so that any consumer in their right mind would buy services from somebody else. And there are third-world telecom monopolies or ex-monopolies that use their position to strangle new competition. (In the US, the worst offenders are mostly cable TV companies, but even in the bad old days of Excite@Home banning anything server-like, they understood that the main reason people bought their service was to file-share pirated music. And in the Pacific Rim, unfortunately Australia's telecom industry has a third-world attitude toward data users.)

But fundamentally, the things Cringely's complaining about aren't accurate, because he doesn't understand the technology or the resulting economics. Yes, telcos are dealing with the threat of VOIP, and it's making their heads explode, and VOIP is much *much* harder to integrate with an old-fashioned telephone infrastructure than to run as a pure-VOIP business. (The technology's difficult, making it scale is difficult, different parts are centralized or decentralized, all the assumptions about who hands money to whom are different, the regulatory infrastructure doesn't match well at all, etc.) And the telcos are making sure that their data networks will support any VOIP services they develop with as close as they can get to traditional telco voice quality, and they're not sure how to deal with the fact that cellphones have convinced the public to accept lower-quality calls and newer codecs with much higher frequencies can support speakerphones much better.

Some big ISPs happen to be owned by telcos, or by telco-wannabees like the cable TV companies. Most of them are working on adding CoS capabilities to their backbones, but that's the least critical part of the network because most of them own their own fiber plants, and it's cheaper for them to burn more wavelengths on their fibers than to add fancy engineering capabilities to their routers or to hire fancy engineers to run them. It's the friendly mom&pop ISPs (that Cringely's not worried about) who are most likely to have backbone congestion issues that need CoS support to prioritize VOIP over best-effort data applications, because they're running at a different scale and don't generally own their own fiber networks.

The places that CoS matters most are the skinny parts of the network - the ingress from the customer's premises to the ISP's POP, and the egress from the ISP's POP to the customer's premises. The ingress direction is really a customer hardware and management problem, making sure that VOIP packets get on the wire before data packets, but service providers (including Vonage) typically handle that by forcing the customer's data through the same box that converts traditional-phone signals to VOIP, and software-based providers like Skype handle that inside the user's PC. This doesn't require the ISP to do anything, though it's sometimes cheaper to build those capabilities into the DSL/cable modem.

The egress direction can benefit from CoS marking, or from other fair-queuing systems that share bandwidth between remote sites or protocol types, or even from dumber systems that prioritize UDP over TCP. In a symmetric environment, like most business T1 connections, this is the most critical part of the system, because data applications can drown out voice unless there's some QoS approach. But most consumer connections are asymmetric, with much faster downstream connections than upstream, so there's less of a problem. Also, in most home applications, if downstream bandwidth is the bottleneck, it's usually because of some application like downloading music that can be turned off or slowed down during phone calls, which isn't a practical approach in most multi-person offices.

Cringely's arguments are especially bogus because the impact of backbone QoS / CoS features on network performance is much smaller than the impact of slow upstream connections in ADSL and Cable Modems. A 12