"We're Not Blocking P2P Traffic" - How Comcast Did It

Cable giant Comcast finds itself in hot water last year when users of their network start having problems with their peer-to-peer (P2P) file sharing. Comcast says, “We’re not blocking P2P traffic.” The Associated Press’s Peter Svenson, on Oct. 19, 2007 writes, “Comcast Corp. actively interferes with attempts by some of its high speed Internet subscribers to share files online, a move that runs counter to the tradition of treating all types of Net traffic equally.” Comcast replies, “We’re not blocking P2P traffic.” Svenson tests this by trying to download the King Jame’s Bible (which is not copyrighted) using a Comcast connection in San Francisco and in Philadelphia. Despite these findings, Comcast still insists that they aren’t blocking P2P traffic.

This dispute generates a lot of net discussion that passes through Comcast’s portion of the Internet unmolested. It is not positive publicity.

The Federal Communications Commission (FCC) eventually takes an interest and tells Comcast to stop blocking P2P traffic. Comcast tells the FCC that they aren’t blocking P2P traffic and suggest that the FCC is not authorized to interfere with Comcast’s management of their own network, anyway. The FCC, after deciding that it’s exactly their mandate to regulate broadband, tells Comcast that they must treat all Internet traffic consistently. Net neutrality thus becomes official US policy. Comcast demurs, and the FCC sets a deadline. Comcast sues, but on the last day before the deadline, Comcast comes clean and answers the FCC. In their answer, they include attachments that describe their past network management activity and their future plans for managing their networks. Comcast publishes these on their website. Interested web journalists take note.

That deadline was Friday 19, 2008. Much has been written about Comcast caving in, but little has been written about the nuts and bolts of how they were actively shaping a certain class of traffic passing through their network. Let’s look at that.

First, let’s look at how Comcast’s high-speed network is organized. It is a hybrid fiber-coax network. Starting from the customer’s network modem in his house, cable runs to a nearby optical node. Several other houses in the neighborhood also connect to the same optical node. The connection then becomes optical fiber. Several of these combine in a hub, and that hub is called a CMTS (cable modem termination system). Comcast says that a typical CMTS port can handle about 275 downstream ports and about 100 upstream ports. This is what provides the asymmetric description of consumer-grade connections – uploads are slower than downloads. The industry refers to this as “provisioning” or more simply, a best-efforts promise to provide a certain level of performance to each customer.

Photo credit jsz0

Comcast, like any other network provider, has a right to employ management practices on their own network. Comcast, some years ago, became aware of significant congestion happening on their networks. Much of this congestion was on the upload side. This is the weaker side of the asymmetric equation, but the unexpected upload traffic volume was causing problems. In their answer to the FCC, Comcast talks about latency, which is packets arriving slowly, and jitter, which is packets arriving with a variable delay.

A packet, in Internet and networking terminology, is the basic unit of network traffic. Each packet consists of a header and a body. The header describes where the packet is bound, and the body contains the content – parts of a web page or an email. The header also contains information about the data’s size, destination, and timing.

Internet users have traditionally been more concerned with download speeds than upload speeds – how fast they can download that track from iTunes or that video from YouTube – and less about how fast they can send – email and file uploads.

The congestion on Comcast’s upstream side surprised them. To further investigate the causes, Comcast joined forces with the Canadian company Sandvine. Together they discovered that the unanticipated traffic was due to “the use of several P2P protocols . . . regularly generating disproportionate burdens on the network, primarily on the upstream portion of the network, causing congestion that was affecting other users on the network.”

To combat the cause of the congestion, Comcast decided to establish thresholds for the managed protocols. Below that threshold, upload traffic is not managed.

The actual device that Comcast used for their traffic shaping is the Sandvine PTS 8210, which went into full deployment in 2007. The PTS 8210 is installed physically close to the CMTS it works with. The purpose of the device is to monitor the upstream traffic going by. Traffic does not ordinarily pass through the device. The flow from many customers is “mirrored” to the device, and it does not delay normal upload traffic.