P2P traffic standards
Someone pointed me today to an IETF workshop held last week at MIT (announcement here) about possible standard-setting activities focused on P2P issues. The workshop was prompted by the Comcast/BitTorrent experience.
This is a good development, in my view. Putting aside the policy implications of the Comcast situation (and the question whether the FCC has or should have jurisdiction to do anything about that situation), the key problem for the globally interoperable internet as a whole is whether network operators are adhering to internet standards.
The cable networking standard, DOCSIS, was designed by CableLabs to be profoundly asymmetrical. More traffic can travel down than up, across widely-shared neighborhood uplinks. As I understand it, the standard also provides for long buffer lengths - lots of packets lining up as TCP fills the buffer - which makes for multi-second lags that are frustrating for VoIP and gamers. Additionally, and somewhat paradoxically, heavy upstream users are automatically sent to the front of the line - “ordinary” interactive users may get stuck behind them. Cable network operators argue that these infrastructural factors, and others, make network management to interfere with heavy P2P use necessary. I understand that DOCSIS 3.0 will increase bandwidth available to cable subscribers - by joining together cable channels - but will still have asymmetry (if perhaps not as profound).
Meanwhile, of course, P2P is extremely useful as a solution to content-distribution issues because it allows for spreading the weight of transmission. Randomly cutting off P2P sessions, or having standards that differ across network operators, will harm innovation.
So while we wait for network operators to upgrade their networks, it would be better for application developers and for the internet as a whole for standards to be developed for application-agnostic congestion control. Hence the IETF workshop.
All the papers for the workshop are here, and there’s a particularly interesting BitTorrent paper (#22 on the list). BitTorrent says:
The IETF could help solve the problem P2P apps currently pose for ISPs and users in these ways:
1. Standardize a mechanism for BitTorrent cache discovery. This is the lowest-hanging
fruit.
2. Standardize a mechanism for conveying information about the network to P2P software, which would enable smarter peer selection, and standardize ways to use this information. Cache discovery could be a part of this potentially more general mechanism or could be separate.
3. Document an experimental approach to end-to-end congestion control that meets the objective of not increasing delay substantially even if bottleneck device buffers are large relative to the bitrate.
4. Publish an informational RFC that documents caching, smarter peer selection, and better congestion control as the best current practices in solving problems caused by P2P.
Take a look. Application-agnostic standards like TCP/IP made internetworking possible in the first place. It would be good to continue with the goal of a globally interoperable, application-agnostic internet.
Comments
4 Responses to “P2P traffic standards”
Got something to say?
You’re seriously confused about Internet protocols. There are two transport protocols in the stack, TCP and UDP. TCP is for short file transfer, and UDP is for real-time applications like VoIP. This is not application-agnosticism, it’s a recognition in the very core of the protocol stack that applications don’t all have the same requirements from the network.
P2P is an innovative new application that has a different set of requirements from either short file transfer (ftp, e-mail, and HTTP) or real-time UDP: it needs lots and lots of bandwidth, but it’s not picky about when it gets it. Hence it warrants a different kind of treatment from the stack than other applications.
I posts like this one you stray far from your area of expertise - law and policy - into the realm of network engineering. This journey is unwise.
Richard - all I said was that TCP-IP itself is application-agnostic. That’s correct.
And the larger point I’m making is that internet-wide standards are important.
Actually, it’s not correct. As the great Tim Wu has said, “In a universe of applications, including both latency-sensitive and insensitive applications, it is difficult to regard the IP suite as truly neutral.”
TCP/IP is so non-neutral that it was necessary to invent UDP/IP at the same time. And these two transports don’t encompass all possible network application paradigms.
So no, the TCP/IP protocol stack is not application-neutral in any meaningful sense of the word.
You may as well be arguing that the poll tax was not discriminatory because it applied to everyone, rich and poor alike.
Susan, BitTorrent isn’t a protocol; it’s a program. A program that seeks to exploit networks — in particular, by shifting bandwidth burdent from content providers to ISPs — multipying them in the process — without permission or compensation. This practice is unfair and simply wrong, and ISPs are justified and well within their rights to block it.