Comcast's Congestion Catch-22

The Catch 22

Here comes the catch-22 for Comcast. Because it implemented a protocol-agnostic system, when the network is triggered to throttle back consumption for heavy users it does not – in fact cannot, given the way the system is implemented – distinguish between different applications. That throttle-back may have a limited impact on Web surfing or email (and will only slow rather than eliminate P2P transfers). But for real-time applications like VoIP, the results can be more drastic, resulting in choppy or even dropped calls.

Again, it’s important to look a little deeper. What VoIP calls are being affected and how? Given the network policies, the only user(s) whose VoIP calls would potentially be affected are from users exceeding their 70% usage capacity limits (since only they see their bandwidth throttled back). According to Comcast, during trials of the system, an average of less than one-third of 1% of all users had their usage levels reduced during any particular day. So here’s the profile of the user whose VoIP calls would be impacted: They’d have to be consuming a large amount of bandwidth (probably via P2P transfer or some other high-consumption use case) and be talking on a VoIP call at the same time.

Also worth noting: Prior to that small number of individuals potentially seeing their VoIP calls impacted, network congestion at that point was impacting all VoIP callers on that network segment. After the congestion system was triggered, only the high-consumption users would have their VoIP calls impacted. Or as Comcast puts it in their FCC filing: “The same thing [VoIP choppiness] could happen to the customers on a port that is congested in the absence of any congestion management [emphasis theirs]; the difference here is that the effects of any such delays are shifted toward those who have been placing the greatest burden on the network instead of being distributed randomly among the users of that port without regard to their consumption levels.”

One final question worth addressing: Why use the potentially invasive DPI approach (or even Comcast’s second, still convoluted method) to manage bandwidth at all? Why not just watch protocol headers or manage particular ports? It’s part of the ongoing game of cat-and-mouse between network operators and their heaviest users, as one source described it. ISPs did those things at one time, but savvy users (and most really high-bandwidth consumers are more savvy than your typical home user) found route-arounds by spoofing headers or moving to less-watched network ports. When the P2Pers got too far ahead of those trying to manage their networks, service providers – for better or worse, and up to now it’s been a bit of both – began inspecting packets to get a better overall “signature” that can help them determine exactly what kind of applications are running over their networks.

As much as this may come off as a defense of Comcast and its network management practices, it’s not. Comcast’s initial network management attempts were heavy-handed at best, arguably unethical at worst. Its second, rushed attempt to meet FCC requirements appears much more measured. But who are we to say that it didn’t foresee the seemingly unintentional benefit it gave its VoIP service versus competitors? It’s impossible to know for certain.

But at a time when all ISPs are trying to determine the best way to manage IP traffic, Comcast’s travails offer lessons — and warning sirens – for all service providers.