Comcast’s CTO Tony Werner was kind enough to give me a few minutes today on the changes afoot in the cable giant’s Internet access network, and I like what I learned. I’ll do a longer post on this later with some diagrams, but for now I’d like to sketch out the high points. This is just from the Comcast side of the agreement, BitTorrent is also committed to making some changes on their end and I don’t have the details on those yet. BitTorrent will be making a presentation at the P4P Forum on its commitments.
Here’s what Comcast is going to do, pending how well it shakes out in the lab:
* Stop injecting TCP RSTs. This technique has been maligned way more than it deserves to be, because it has such a long history. Middleware devices (of which Sandvine is only one) have been doing this for at least a decade, drawing the ire of the IETF for it all along. It’s not necessary in a DOCSIS network for technical reasons, so they’re going to stop doing it. This should make the “Comcast is Impersonating You and Stealing Your Credit Card Numbers!!!” crowd happy.
* Start using CMTS scheduling to allocate bandwidth fairly among all users of a first-hop segment when the network is heavily loaded. The DOCSIS protocol permits packet scheduling, since every user has to request bandwidth for every upstream transfer, so all the CMTS has to do is implement Fair Scheduling to prevent bandwidth hogs from getting more than a fair share. There may be some limits to the delay the scheduler can impose (my conjecture, not Tony’s,) and that’s why field testing is important.
* Investigate longer-term solutions that will allow users to control how different traffic streams are handled. There are a number of IETF standards that relate to this problem, and their evaluation will be long-term work items for the industry forums.
CMTS scheduling puts Comcast on the same footing as the DSL providers. While Comcast customers share a first hop and DSL doesn’t (most of the time, they actually do if repeaters are used), all of them share a second hop, access to which is mediated by a fair queuing discipline. So Comcast is simply implementing their queuing discipline on the first hop, which makes good sense for their technology. So there’s no need to look at protocols and headers, it’s all just traffic and traffic opportunities can be managed with per-user fairness.
So the bottom line is this: the IETF protocols failed to deliver a scheme for per-user fairness, so Comcast will implement one on their first hop network. That’s what we call progress, and the only question is why it took them so long to do it.
I frequently upload dozens of pictures to my web site via FTP through Comcast’s network. I have seen two changes in speeds in the last few months. First, a couple of months ago I was lucky to get a sustained 384 kilobits per second on upload, now I get a minimum of 1 megabit per second. Interestingly, for the first 10 megabytes of transfer, I get peak speeds of 2.5 megabits per seconds. After that, the network appears to throttle back to 1 megabit per second. This is not BitTorrent, just plain old FTP of JPEG pictures, which average about 2 megabytes each.
I am paying the premium for Comcast’s highest tier of service. On a good day I speed test at 12 megabits per second download.
I think Comcast’s new non-discriminatory (by content) traffic shaping is already in place on my segment.
I think you’ve got the Powerboost technology, which is mainly dynamic caps and less dense deployments, but not the newest new thing. You probably wouldn’t see any difference unless you seed new Torrents, which you probably don’t (most people don’t.)