Slashdot Mirror
Another Inventor of the Internet Wants To Gag It
MojoKid writes "Lawrence Roberts is just another guy with the title: 'Inventor of the
Internet' in news articles. According to Wikipedia, he's the
father of networking through data packets. And he's
turned his attention to everyone's favorite data packet topic: Peer-to-Peer
file sharing. He's established a company called Anagran, and says their devices
can sort out which file transfers on the tubes are P2P, and — you guessed it — can throttle them in favor of other, more 'high-priority' traffic."
And so does Cerf, and all of the other co-called inventors, and fathers. They got us into this mess.
Someone needs to sort out egalitarian access, hopefully some visionaries and NOT a large group of non-vendors, so that the process can be as inclusive as possible.
My suggestion: two channels, one for QoS-respected traffic, the other free-for-all. The QoS channel costs you, per period time. The free-for-all is all you can eat. Vary the mix you want to purchase, or offer at your free hotspot or WebbieTubeBar. You get what you pay for, no more, and less if you don't use it.
The pontiff approach ain't working.
---- Teach Peace. It's Cheaper Than War.
Oh, the virtual circuit guy. I interviewed with Telenet when they had 13 employees, so I met him in the 1970s. Telenet HQ was in a big mansion-like house. It seemed too weird to succeed, and I didn't want the job.
The virtual circuit vs. datagram battle is almost forgotten now, but it was a major issue before fiber optics provided vast cheap long-haul bandwidth. Remember, the ARPANET backbone was only 56Kb. Long-haul leased bandwidth was incredibly expensive through the 1980s.
If the backbone bandwidth is the constraint on network traffic, congestion management of a pure datagram network is very tough. I had to run such a network in the early 1980s, which is why I have all those classic RFCs and papers on network congestion. We figured out how TCP should play nice to avoid congestion collapse, and how fair queuing could give the network some defenses against overload. That was enough to make a network of reasonably-well behaved nodes not doing anything with real-time constraints behave.
In the days of congested backbones, virtual circuits were looking like the future, because they were more manageable. Bandwidth could be assigned at connection setup, and each connection throttled. Tymnet and Telenet worked that way. That approach became obsolete when local area networks became widely used; none of them were virtual circuit, so the backbone had to be at the datagram level. Then fibre optics came along and saved the backbone.
We still don't really know what to do when the backbone is the bottleneck and latency matters. "p2p" file transfer isn't the problem, though. HDTV over the Internet is the problem. There isn't enough backbone bandwidth to support the world's couch potatoes with real-time HDTV streams.
Microsoft at one point proposed a system where real-time HDTV would be multicast, while video on demand would be heavily buffered. That could work, but multicasting with bandwidth guarantees requires more centralized control than the Internet usually has today, which is probably why Microsoft and parts of the broadcast industry liked it.
The "p2p" thing is a side issue. The big issue is going to be who gets to throttle whose HDTV streams. The cable guys want really, really bad to charge extra for those streams, regardless of who originates them.
Also mod it down because the article is completely misleading - Lawrence Roberts doesn't want to gag P2P at all. He wants to help it survive in a practical manner.
The problem he wants to solve is how to make someone who's trying to bring up a quick mapquest page be able to do so without sitting there waiting and waiting, and eventually wondering whether there're five people on his subnet downloading the latest 18G celebrity midget porn video. If he solves that problem, then Comcast won't care about using more stupid methods of throttling our celebrity midget porn.
I heard this guy speak a the recent Structure08 conference.
The way his solution works isn't throttling and doesn't rely on protocol inspection, nor does it target P2P directly.
Instead, it ensures fair bandwidth between users, rather than between flows. Basically his argument is that the problem isn't P2P, it's just that P2P happens to make it hard to share bandwidth because of the huge number of connections it uses. His box makes sure bandwidth is shared fairly between users, regardless of the number of connections they are using. So if you have 10mbit, and 10 users, and all are trying to download something, each will get 1mbit, even if one user is using 10 connections and the others are using 1.
It's certainly an interesting approach to dealing with the problem.