Author: RB

An Op-Ed about net neutrality in last week’s Seattle Times by Avis Yates Rivers makes all the obvious points: solution in search of a problem, treatment worse than the disease, etc., including this one:

Because a network’s bandwidth is a finite resource, the management tools function like traffic lights and yield signs. They seek an orderly way to allow heavy P2P-like traffic to flow without interfering with other users. At peak times, these tools send a signal to a high-bandwidth user that they will find the requested content when a lane opens on the information highway.

But wonders never cease, and David Isenberg found it wrong and offensive:

So mostly Yates Rivers is wrong when she says that bandwidth is finite. Where it is finite, the blame lies at the feet of the telcos . . . well, not really, they wouldn’t be so stupid as to build such abundance that they have nothing to sell anymore. The blame lies with our limited vision — we have affordable, mature technology that would make bandwidth scarcity as obsolete as horsepower from horses.

Can Isenberg really be this stupid? He worked for Bell Labs for 12 years, presumably doing something more technical than sweeping floors, but he still makes bonehead statements like this. I can only conclude that he’s lying deliberately.

Yes, Virginia, bandwidth is finite and it always will be. Even when we have gigabit access connections, we’re still counting on everybody not using theirs full-tilt at the same time. For every consumer of data there’s a producer, and for every pair of consumer/producers there’s a carrier, and every link has its limit. Beef up the core, and the access network becomes a bottleneck. Beef up the access network and the core becomes a bottleneck. That’s life.

Reading blogs about network neutrality is a never-ending source of fun. This comment from the Save the Internet Blog about Verizon’s open wireless network is choice:

Verizon customers will be able to use non-Verizon cell phones and applications like GPS, but what about the rest of us?

What about the rest of us non-customers indeed.

Nemertes Research speculates that investment in residential networks isn’t keeping pace with user demand for bandwidth, hence a bandwidth crunch will come about in 2010 or so. Their method is to assume that bandwidth appetite follows Moore’s Law and investment is linear, therefore the lines have to cross.

They may very well cross, but their math is wrong. One of the corollaries of Moore’s Law is that circuits grow cheaper as you pack more of them on a die, hence a linear investment in technology should result in a pool of bandwidth that accommodates Moore’s Law increases in demand. Moore’s Law applies at both sides of the network interface, in other words.

There is a caveat, however: communication networks are hybrid systems, part analog and part digital, and only the digital part obeys Moore’s Law. The way around this is to engineer them to minimize the role of analog, which is what we did when we moved Ethernet from shared coaxial cable to point-to-point twisted pair on a silicon hub. It costs more to upgrade bandwidth on shared-cable systems like DOCSIS than on dedicated cable systems like FTTH. So the real issue is getting a cable plant in place that facilitates Moore’s Law economics.

Predictably, the regulation fanatics fail to deal with any substantial issues in relation to this study, and simply throw poo at the walls of their cages. See: Save the Internet, and DSL Reports. An ad hominem is not an argument, and Nemertes refuted Save the Internet smartly in the comments.

Nobody knows, of course, how fast user demand for bandwidth will grow in the next few years, but it’s inextricably bound with how fast carriers deploy fatter pipes. At some point, we will get our TV shows in HD over an IP network or something similar, and even that (100 Mb/s or so) won’t be the final upper limit.

This is impressive:

Verizon Wireless today announced that it will provide customers the option to use, on its nationwide wireless network, wireless devices, software and applications not offered by the company. Verizon Wireless plans to have this new choice available to customers throughout the country by the end of 2008.

Does it signal VZ’s intention to bid on the 700 Mhz C block? Fleishman thinks so.

One thing it does show is that markets are more efficient than regulators, which is why the regulation-happy crowd is silent on it*. Tim Wu in particular should have something to say as he’s the one who petitioned the FCC for Carterfone-like regulations on cellular networks.

Let’s see.
—
*UPDATE: Harold Feld takes respite from his painful loss at the FCC today to take credit for Verizon’s move. I don’t think so, and here’s my alternate theory: Verizon has figured out that winning in the marketplace requires superior technology. Don’t tell Harold, he’ll be sad.

A couple of weeks ago, I mentioned an academic paper on cable modem (DOCSIS) – TCP interaction which highlighted a couple of problems. The authors maintain that web browsing doesn’t interact efficiently with DOCSIS, and that DOCSIS is vulnerable to a DoS attack based on packet rate rather than data volume. DOCSIS mechanisms that cap downstream traffic don’t protect against the DoS attack, which is based simply on packet rate rather than volume. I said:

In effect, several BT streams in the DOCSIS return path mimics a DoS attack to non-BT users. That’s not cool.

It’s not clear to all of my network analyzing colleagues that I was correct in drawing a parallel between BitTorrent and the DoS attack, so here’s a little context from the original paper:

Denial of Service Study
The previous analysis showed that downstream TCP transfers are impacted by the DOCSIS MAC layer’s upstream best effort transmission service. In this section we show that it is possible for a hacker to take advantage of this inefficiency by initiating a denial of service attack on CMs that can cause high levels of upstream collisions resulting in serious performance degradation. To accomplish the denial of service attack, a host located outside the network must learn the IP address of a number of CMs that share the same downstream and upstream channels. The attacker simply needs to ping or send a TCP SYN packet to the CMs at a frequency that is on the order of the MAP_TIME setting. The actual frequency, which might range from once per MAP_TIME to once every 5 MAP_TIMEs, is a parameter of the attack.

A couple of things will help clarify. The researchers say it’s only necessary to send TCP SYNs at a frequency that resembles a multiple of the network’s scheduling period. A TCP SYN is a connection request, the thing that the infamous TCP Reset (RST) cancels. It’s part of the fabulous three-way handshake that starts a TCP connection (SYN -> SYN/ACK -> ACK) and is a very frequent part of BitTorrent interactions during seeding, as leeches are connecting to seeders and seeing what sort of rate they can get. The significance is that these are short packets which, in high frequency, cause a large demand for upstream transmit opportunities, a scarce commodity in DOCSIS.

So a relatively small number of BitTorrent seeds can place a high load on the upstream path with very little data, and can’t be controlled by bandwidth caps. DOCSIS allows piggybacking of bandwidth requests, which alleviates the problem of contention slot exhaustion for steady streams, but it’s only effective when a lot of data is queued. If several modems are dealing with a large number of responses to connect requests, other modems that are simply supporting web surfing will starve because they too will have to compete for limited contention slots to ACK the data they’re getting.

This is a very different scenario than the Internet congestion case that’s addressed by dropping packets and backing-off on TCP pipelining. The response rate to connection requests is only governed by the rate at which the connecton requests arrive, and dropping packets on established connections doesn’t affect it. And there’s the further complication that this is a first-hop congestion scenario, while Internet congestion is an intermediate hop scenario. The rule of congestion is to drop before the congested link, and if that happens to be the first link, the dropping agent is the customer’s computer or the BitTorrent leech who’s trying to connect to it.

So this can only be addressed by limiting connection requests, which can be done in real-time by routers that can inspect every incoming TCP packet for the SYN bit and keep track of total connections. The Comcast alternative is to asynchronously monitor traffic and destroy connections after the fact. It’s not as efficient as stateful packet inspection, but the gear to do it is a lot cheaper. Given their Terms of Service, which ban servers on their network, it’s sensible.

So the debate comes back to the question of the legality of Comcast’s TOS. The FCC says ISPs can’t limit the applications that customers can run, and BitTorrent is certainly an application. It strikes me as unreasonable to demand that every ISP satisfy every application requirement, and it’s a certain path to the destruction of VoIP if they must. These asymmetrical residential networks aren’t going to do well with lots of VoIP and lots of Torrents, so something has to give if the law is going to insist on this Utopian goal.

I hope that clears things up.

The Heritage Foundation has graciously transcribed the discussion we had a couple of weeks ago on Comcast, featuring Adam Thierer, Jerry Brito, Ed Felten, James L. Gattuso and yours truly.

The Comcast Net Neutrality Controversy: A Discussion

On October 25, the Technology Liberation Front, a technology policy weblog, hosted an online discussion concerning recent actions by Comcast Corporation to limit certain types of traffic on its network in order to manage demand. This is an edited transcript of that discussion.

The actual podcast is here.