Comcast cops to BitTorrent busting
Eight months later
Eight months after an independent researcher revealed that Comcast was secretly throttling BitTorrent and other P2P traffic, the beleaguered American ISP has at last admitted that's exactly what it's doing.
Of course, Comcast thinks this throttling is one great idea. And the company continues to deny it did this for months without properly notifying customers.
In a new filing with the US Federal Communications Commission (FCC), Comcast says it "manages the use of certain P2P protocols in a minimally intrusive way, and only when necessary, based on purely objective criteria".
The filing is a response to petitions lobbed at the FCC by various members of the SaveTheInternet coalition in early November. By early January, the FCC agreed to investigate Comcast's "network management", and a public notice was soon filed by the commission's Wireline Competition Bureau.
Comcast explains that its BitTorrent busting is "not based on the content of the files users are sharing or the identity of the users who are doing the sharing." And it's responsible for all those italics.
But then the company describes exactly when - and to a certain extent how - it "manages" P2P traffic. It's techniques -
- only affect the protocols that have a demonstrated history of generating excessive burdens on the network
- only manage those protocols during periods of heavy network traffic
- only manage uploads
- only manage uploads when the customer is not simultaneously downloading (i.e., when the customer’s computer is most likely unattended) (“unidirectional sessions” or “unidirectional uploads”)
- only delay those protocols until such time as usage drops below an established threshold of simultaneous unidirectional sessions.
So there you have it. Comcast throttles your BitTorrent uploads only when you're most interested in uploading them.
As the company has said before, it believes that this network management is "reasonable" and that it is "fully consistent" with the FCC's 2005 Internet Policy Statement.
Certainly, you can argue that Comcast is well within its rights. But what gets us is the company's inability to openly discuss its practices.
When an independent researcher first revealed that Comcast was throttling P2P traffic, the company flatly denied this was going on. Then, late last week, when we ran a story about new changes to the ISPs terms of service, or High-Speed Internet Acceptable Use Policy, the company denied that these changes were a direct response to the ongoing questions concerning its network "management".
But then, just days later, in its FCC filing, the company has this to say:
Comcast recognizes the importance of providing its customers with appropriate disclosures about the services they purchase. Accordingly, Comcast’s customer service agreements and policies have always informed Comcast customers that broadband capacity is not unlimited, and that the network is managed for the benefit of all customers. Nonetheless, in a continuing effort to ensure that consumers have the information they need, Comcast recently updated its High-Speed Internet Acceptable Use Policy (“AUP”) and Frequently Asked Questions (“FAQs”) to provide greater transparency in how it manages its network.
Nonetheless, when we spoke to the company again today, it again denied that it spent that last several months pulling the wool over its customers eyes - and it again denied that its new terms of service were a direct response to the FCC's investigation.
Keep it up, Comcast. This is great theatre. ®
It seems to me that ...
... the "problem" is trying to control traffic before it gets to their first upstream box capable of 'normal' queuing/throttling. Ie, unlike ADSL where the uplink is a non-shared resource until it gets through the mux at the exchange, here we have a shared medium with multiple users fighting over it.
In this case, it does seem like the only, but very drastic, measure available is to terminate the session(s) that take up too much of the shared medium.
From comments I've read, and I have no direct knowledge of this, it does sound like modern cable kit DOES support some form of traffic control where it is needed, so the question really should be "why doesn't this ISP use it ?" I suspect the answer is porbably something along the lines of "We don't want to spend any money on it !" which seems to be the response of UK ISPs to criticism that their networks are over congested and need upgrades !
@Impersonation, and the technical difficulties argument.
The telephone company has the right to manage traffic on their network too, but if they tried to do it by getting you to use your phone less, by calling you up with the spoofed caller ID of a friend and faking a message in their voice telling you never to call them again, you wouldn't think it anything less than completely clear cut.
The examples you gave /don't/ muddy the waters all that much. Transparent http proxies don't alter the content. If they /do/ alter the content (such as Rogers have been doing lately), it is seriously controversial, as recent events have shown.
So the degree of acceptance toward ISPs' impersonation practices that currently occur is _predicated_ on them not *interfering* with your use of the service nor *falsifying* the data through abuse of their position, which is essentially that of a man-in-the-middle. Conveying our packets is a very serious social and moral responsibility, like conveying our postal mail or phone calls, and tampering with either should be equally taboo.
Re. the technical difficulties argument: I'm not buying that one either, or only marginally convinced that it couldn't be addressed pretty straightforwardly using existing technologies and only a modicum of development and deployment effort. If you can spot a p2p syn+ack packet flying across the network and send a rst, you can just as easily slap a tag on the traffic and shunt the punter sideways onto a lower traffic priority vlan, or I would like to know why not?
One problem with the "impersonation" argument against Comcast's behaviour is that many ISPs impersonates services to some extent.
A common one is to redirect port 80 requests to their proxy server so they can cache pages, reducing use of their internet links and providing better service to their users.
Another is redirecting SMTP connections to their server, so they can monitor the traffic (and potentially cut off spammers). This one is a bit more controversial, and is a pain if you are trying to access a corporate SMTP server while on the road.
Now I realise that these two examples are quite different to inserting TCP reset packets into an overwise untouched stream, but it makes arguments like "the ISP should never interfere with customer TCP connections" a bit less clear cut.