Thursday, August 5, 2010

In Which, From Our Position Just in Front of the Fan, We Observe a Cluster of Moist Brown Objects on a Ballistic Trajectory Toward Us

I've always been OK with regulation for location neutrality on the internet while opposing application neutrality because it can stifle protocol innovation. Now it appears as if some of the Big Boys may be about to force the issue:
Google and Verizon, two leading players in Internet service and content, are nearing an agreement that could allow Verizon to speed some online content to Internet users more quickly if the content’s creators are willing to pay for the privilege.

The charges could be paid by companies, like YouTube, owned by Google, for example, to Verizon, one of the nation’s leading Internet service providers, to ensure that its content received priority as it made its way to consumers. The agreement could eventually lead to higher charges for Internet users.
Now, it's possible that the NYT is simply casting this in the most negative light possible but, if true, I can't think of a better way of chumming the water for the net neutrality sharks to begin a full-on feeding frenzy. It's abysmally stupid.

Note that there is a serious engineering issue here. When we use DSCP to mark packets, there's a bit of a gentlemen's agreement that we use the proper code point for a particular application. If you suddenly start using different markings for the same application, you're now essentially practicing location discrimination. You can do some amount of verification that applications are being nice via policy, but it gets tricky.

I'm not entirely opposed to the idea of paying for quality of service. Indeed, paying for QoS to enable certain types of applications (for video over IP or gaming or teleoperation, for example) is almost essential. But you want that tariffing to be directed at the content consumer, not the provider. Otherwise, you get to the point where large, rich content providers can choke out the smaller guys. (Note that conversational communications is a special case, in that both ends of the stream are both consumers and providers.)

Could this all be solved by simply enforcing neutrality on all TCP traffic? This would obviously provide an (undesirable) incentive for content providers to move to UDP-based protocols, as BitTorrent has already done. It would be easier in theory to enforce clean classifications of applications with UDP and to prevent abuses of policy, but you still have the problem of what to do with encrypted traffic. Maybe you only deal with encrypted traffic best-effort, and rely on protocols like sRTP for conversational traffic that needs to be kept private.

Damn, we're on the slippery slope. I'm not sure I want to think too much about the composition of the mud.

UPDATE 14:54 EDT:

Well, this is a little better:
"People get confused about Net neutrality," Schmidt said. "I want to make sure that everybody understands what we mean about it. What we mean is that if you have one data type, like video, you don't discriminate against one person's video in favor of another. It's OK to discriminate across different types...There is general agreement with Verizon and Google on this issue. The issues of wireless versus wireline get very messy...and that's really an FCC issue not a Google issue."
This jibes reasonably well with my position, but I'm hard-pressed to figure out how you distinguish one kind of TCP traffic from another. It's still a bit of an unforced error.

No comments: