Such methods as deep packet inspection and QoS have also drawn the ire of NN dogmatists, so it wouldn’t benefit Comcast any to use them instead of the ad hoc admission control they’re using.

One thing I’ll gladly concede is that Comcast hasn’t handled the media and public relations aspect of the kerfuffle at all well, and haven’t even defended themselves from the charges of identity theft lobbed from Susan Crawford et. al. The game of blog journalism is rough and tumble, and Comcast is too polite and too aloof to play it well.

I’d still like to know why Rogers and Shaw seem to be able to manage P2P traffic using QoS and deep packet inspection instead of spoofing RST packets, considering they use the same version of DOCSIS. And why is Comcast focusing on a single protocol? There are lots of internet applications causing node saturation that Comcast could limit. A protocol-neutral solution would be less likely to draw ire from net neutrality advocates.

Also, wouldn’t you agree that Comcast would appear less sinister if instead of manipulating network traffic, policies were implemented to discourage demand for bandwidth? What about providing customers a finite amount of upstream bandwidth during peak hours, or charging extra to individuals who want to use Bittorrent without their connections being terminated? These methods really wouldn’t be too hard to deploy. In fact, Comcast allegedly has a tiered pricing model ready to roll out but they are scared to do it. But what are they scared of? Surely, the blog hell they’re experiencing at the moment is far worse than if they had designed a transparent, clear-cut method for allowing customers to work within Comcast’s limitations.

Such methods as deep packet inspection and QoS have also drawn the ire of NN dogmatists, so it wouldn’t benefit Comcast any to use them instead of the ad hoc admission control they’re using.

One thing I’ll gladly concede is that Comcast hasn’t handled the media and public relations aspect of the kerfuffle at all well, and haven’t even defended themselves from the charges of identity theft lobbed from Susan Crawford et. al. The game of blog journalism is rough and tumble, and Comcast is too polite and too aloof to play it well.

I’d still like to know why Rogers and Shaw seem to be able to manage P2P traffic using QoS and deep packet inspection instead of spoofing RST packets, considering they use the same version of DOCSIS. And why is Comcast focusing on a single protocol? There are lots of internet applications causing node saturation that Comcast could limit. A protocol-neutral solution would be less likely to draw ire from net neutrality advocates.

Also, wouldn’t you agree that Comcast would appear less sinister if instead of manipulating network traffic, policies were implemented to discourage demand for bandwidth? What about providing customers a finite amount of upstream bandwidth during peak hours, or charging extra to individuals who want to use Bittorrent without their connections being terminated? These methods really wouldn’t be too hard to deploy. In fact, Comcast allegedly has a tiered pricing model ready to roll out but they are scared to do it. But what are they scared of? Surely, the blog hell they’re experiencing at the moment is far worse than if they had designed a transparent, clear-cut method for allowing customers to work within Comcast’s limitations.

And so in effect are applications such as iChat, which send lots of traffic upstream. I find that an iChat session with someone on a cable network is generally terrible. They get a great picture from me, while I get a blocky bunch of pixels since their upload speed is atrocious.

Having cable networks really defeats the idea of having dumb networks and smart applications.

And so in effect are applications such as iChat, which send lots of traffic upstream. I find that an iChat session with someone on a cable network is generally terrible. They get a great picture from me, while I get a blocky bunch of pixels since their upload speed is atrocious.

Having cable networks really defeats the idea of having dumb networks and smart applications.

Servers violate these assumptions, and make network access hell for everybody. Comcast bans servers inside its network, and that’s just what a BitTorrent seed is.

BitTorrent downloads aren’t affected, and neither is seeding at the same time that a download is taking place.

So what’s the problem?

You ask: “Why do they throttle by sending RSTs rather than dropping packets or adjusting behavior at the DOCSIS level?”

If the problem is that excessive requests for upstream bandwidth result in collisions, and the number of requests that rate as “excessive” is small, then there really isn’t anything they can do short of RSTs to reduce the number of requests, is there?

And yes, overprovisioning the network would defer the problem, but they’d rather spend the money that would take upgrading to DOCSIS 3.0. I don’t blame them, it’s a wise move.

The paper you cite points out inefficiencies in DOCSIS (when used with TCP, which it almost always will be). But it doesn’t provide technical justification for the steps Comcast is taking. The paper’s main result is that DOCSIS has trouble when lots of users are browsing the Web. Then why doesn’t Comcast throttle Web traffic? Why do they throttle by sending RSTs rather than dropping packets or adjusting behavior at the DOCSIS level? Isn’t the real problem that their network is underprovisioned, with too many users sharing the same termination system?

Servers violate these assumptions, and make network access hell for everybody. Comcast bans servers inside its network, and that’s just what a BitTorrent seed is.

BitTorrent downloads aren’t affected, and neither is seeding at the same time that a download is taking place.

So what’s the problem?

You ask: “Why do they throttle by sending RSTs rather than dropping packets or adjusting behavior at the DOCSIS level?”

If the problem is that excessive requests for upstream bandwidth result in collisions, and the number of requests that rate as “excessive” is small, then there really isn’t anything they can do short of RSTs to reduce the number of requests, is there?

And yes, overprovisioning the network would defer the problem, but they’d rather spend the money that would take upgrading to DOCSIS 3.0. I don’t blame them, it’s a wise move.

The problem Comcast needs to address is at neither the TCP layer or the IP layer, it’s lower down at the MAC layer. The cable modem protocol, DOCSIS, requires each user to request bandwidth for upstream transfers one packet at a time. All applications using TCP or even UDP with feedback need to send upstream ACKs even if most of their traffic is downstream.

The problem that DOCSIS has is that the bandwidth request packets are sent in a slot in which all the cable modems on the wire are permitted to transmit, so these packets are lost under high load due to collisions. When the bandwidth request fails due to a collision with other bandwidth requests, the cable remains idle in the upstream direction and nobody gets to transmit. So everybody’s user experience goes to hell.

Delaying or discarding IP packets will not alleviate this problem, it will simply cause more retransmissions and essentially make it worse. The only way out in DOCSIS 1.1 and 2.0 is to reduce the number of bandwidth requests, which is what Comcast’s method does.

From a network engineering perspective, Comcast is behaving pretty much as they should behave. Please read the paper I cited in the previous comment: The Interaction Between the DOCSIS 1.1/2.0 MAC Protocol and TCP Application Performance. It’s not that hard to understand this: “Figure 5 shows that the collision rates get extremely high as the number of active CMs increase. When only 100 users are active, the collision rate is about 50%. What makes this result alarming is that the web traffic model accounts for the heavy tailed distribution associated with web user idle times.

Consequently, the number of users actually competing for bandwidth at any given time is much less than 100. As the load increased, the collision rate approached 90-100% depending on the MAP_TIME setting.”

Comcast has to reduce the rate of DOCSIS collisions to keep customers happy. The method they use is the best one going.
~

The paper you cite points out inefficiencies in DOCSIS (when used with TCP, which it almost always will be). But it doesn’t provide technical justification for the steps Comcast is taking. The paper’s main result is that DOCSIS has trouble when lots of users are browsing the Web. Then why doesn’t Comcast throttle Web traffic? Why do they throttle by sending RSTs rather than dropping packets or adjusting behavior at the DOCSIS level? Isn’t the real problem that their network is underprovisioned, with too many users sharing the same termination system?

The problem Comcast needs to address is at neither the TCP layer or the IP layer, it’s lower down at the MAC layer. The cable modem protocol, DOCSIS, requires each user to request bandwidth for upstream transfers one packet at a time. All applications using TCP or even UDP with feedback need to send upstream ACKs even if most of their traffic is downstream.

The problem that DOCSIS has is that the bandwidth request packets are sent in a slot in which all the cable modems on the wire are permitted to transmit, so these packets are lost under high load due to collisions. When the bandwidth request fails due to a collision with other bandwidth requests, the cable remains idle in the upstream direction and nobody gets to transmit. So everybody’s user experience goes to hell.

Delaying or discarding IP packets will not alleviate this problem, it will simply cause more retransmissions and essentially make it worse. The only way out in DOCSIS 1.1 and 2.0 is to reduce the number of bandwidth requests, which is what Comcast’s method does.

From a network engineering perspective, Comcast is behaving pretty much as they should behave. Please read the paper I cited in the previous comment: The Interaction Between the DOCSIS 1.1/2.0 MAC Protocol and TCP Application Performance. It’s not that hard to understand this: “Figure 5 shows that the collision rates get extremely high as the number of active CMs increase. When only 100 users are active, the collision rate is about 50%. What makes this result alarming is that the web traffic model accounts for the heavy tailed distribution associated with web user idle times.

Consequently, the number of users actually competing for bandwidth at any given time is much less than 100. As the load increased, the collision rate approached 90-100% depending on the MAP_TIME setting.”

Comcast has to reduce the rate of DOCSIS collisions to keep customers happy. The method they use is the best one going.
~