Comcast: Testing Hanlon’s Razor
“Never assume malice where stupidity is a sufficient explanation.”
I’m not sure which of these explains Comcast’s bandwidth “throttling” technique. I put “throttling” in quotes because it isn’t really throttling. It all comes down to one sentence, found on page 10 (the eleventh PDF page):
When the number of unidirectional upload sessions for any of the managed P2P protocols for a particular Sandvine PTS reaches the pre-determined session threshold, the Sandvine PTS issues instructions called “reset packets” that delay unidirectional uploads for that particular P2P protocol in the geographic area managed by that Sandvine PTS. The “reset” is a flag in the packet header used to communicate an error condition in communication between two computers on the Internet.
A reset packet does not indicate an error condition between two computers. A reset packet represents an unexpected, fatal condition on one of the computers, such as an “aborted application” or “no listening service.” This causes the unilateral termination of that data stream between two hosts. There is no “delay” involved, as claimed in the previous sentence. It is not “throttling,” as in constriction; it is closer to “decapitation.”
Furthermore, for a reset packet to be valid, it should come from the other host in the conversation. Comcast’s equipment is forging reset packets, mis-representing their true origin. This behavior from a private individual would be called a “DoS attack,” and would result in ISP account termination, possible lawsuits, and maybe even federal criminal charges.
To handle network congestion properly, the correct message to indicate dropped packets is an ICMP “source quenched” message, following RFC 792.
Either someone at Comcast is ignorant to make this claim, in which case a pink slip is in order; or someone is maliciously mis-leading the FCC, hoping nobody is well-versed enough to notice this bogus statement. I have contacted the FCC regarding this matter.
(Thanks to corsec67 on Slashdot.)