Comcasts Spells Out Congestion Management Plans
Back in March, CDT welcomed Comcast’s announcement that it would move to a “protocol agnostic” technique for managing network congestion. No technical details were provided, but the announcement certainly seemed to imply that the new technique would steer clear of singling out particular protocols, services, or content for inferior treatment. In other words, it would avoid the kind behavior that gives Internet neutrality advocates fits and that puts network operators in a position to undermine unfettered innovation. To use a potentially loaded term, the announcement seemed to imply that the new technique would be neutral. But we also noted that we would have to wait and see how the new technique actually works. However promising the term “protocol agnostic” might sound, it doesn’t exactly have a widely accepted meaning.
Well, Comcast has now filed with the FCC a description of the new congestion management technique it is rolling out. Based on that description, it appears to be the real deal. Simply put, the new technique appears not to hinge on what applications or content a subscriber chooses to access. All it will know or care about is the volume of data each subscriber is sending over the network. When a particular part of the network starts experiencing heavy usage, the subscribers currently generating the most traffic (relative to the size of the connection they have purchased) will end up getting assigned a lower priority. As a result, their traffic may get slowed or perhaps experience some packet drops — but only if overall usage is so high that affecting someone’s traffic in this way is inevitable, and only until the affected individuals lower their usage a bit. Yes, this system may force the highest volume users to bear the brunt of congestion. But these are also the users who are contributing the most to the congestion. And it sounds like no communications sessions get abruptly terminated, as was happening to certain attempted uploads under Comcast’s now notorious “reset packet” technique. Above all, the new technique doesn’t pay any attention whatsoever to the contents or protocol of a subscriber’s traffic; Comcast focuses on volume of a subscriber’s usage, but what exactly that subscriber is doing with that volume is none of Comcast’s business.
I can see a few possible questions or objections. First, could this method unduly discourage usage of high-volume applications such as Internet video (which just happens to compete against Comcast’s cable TV offerings)? Maybe, but the real issue raised by this question is whether Comcast is doing an adequate job of upgrading its network capacity over time. The new congestion management technique should have a concrete impact on high-volume users only when the overall demands on the network exceed its capacity. As a practical matter, occasional and scattered congestion conditions may be inevitable on a network that is evolving as rapidly as the Internet. But Comcast expects the percentage of subscribers actually affected by congestion management to be quite low.
According to Comcast, in trials less than one-third of one percent of subscribers get assigned a lower priority on any given day. If the number of affected subscribers ends up being higher than anticipated, or if it increases over time, that would be a strong sign not that the congestion management technique is flawed, but rather that there is too much congestion — in other words, that the capacity of the network isn’t keeping up with evolving demand. That’s an important issue that is worth keeping an eye on. (Similarly separate from Comcast’s new real-time congestion management technique is Comcast’s recent announcement of an overall monthly usage cap of 250 GB for residential subscribers. This too is worth keeping an eye on, as setting an overly restrictive monthly cap that fails to keep pace with evolving bandwidth demands could have much the same effect as failing to invest adequately in network bandwidth, in terms of discouraging usage of high-volume applications. But the question of overall monthly usage caps is a distinct issue from the new real-time congestion control.)
Second, ideally subscribers would be able to determine when and if they are being affected by the congestion control technique. But at least for the moment, it does not appear that Comcast is providing such a capability. We’re hoping Comcast will move in that direction.
Third, for those subscribers who are sometimes affected, how serious could the impact be? For example, how might it affect latency-sensitive applications like VOIP? Because the technique doesn’t pay attention to protocol, it can’t tell the difference between a subscriber’s VOIP bits and his/her file download bits (which presumably are less time-sensitive) — they all get the same level of priority. Of course, if a subscriber experienced an actual problem, he or she could always scale back on the downloading while the VOIP conversation is going on; Comcast says that VOIP alone would not be enough to trigger the lowered priority. (Alternatively, as CDT has said before, it would not pose any neutrality concerns for a carrier to allow subscribers to select different priority levels for different applications, so long as the choice is really the subscriber’s.)
In any event, the big picture point is that Comcast’s new technique shows that it is possible to devise congestion control tactics that don’t discriminate based on traffic content. Dealing with congestion does not require abandoning the idea of a neutral Internet or giving network operators the ability to decide which applications will get good priority and which won’t.