Slashdot Mirror

The article states that this is a "disposable solution. Their intent is a drop and go process. This is less appealing with a thousand dollar laptop or other devices with aforementioned IP stack. More dreamcast mod info here

The pro and anti QOS issue is quite old. When I first developed fair queueing, it was obvious to me that the queuing system could be biased to be "unfair", and that this would aid in making the Internet a billable transmission system. I deliberately didn't put that in RFC970, because I didn't want to make that happen.

A truism of modern transmission systems, including voice telephony, is that the billing process costs more than actual transmission. Worse, once you have a traffic-based billing system in place, prices tend not to decline as rapidly as tranmission costs decline. This is the major argument against QOS in the Internet.

John Nagle

Programmers get very attached to their favorite languages, and I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub.. is not the most powerful language, but it is more powerful than Cobol or machine language.

When we switch to the point of view of a programmer using any of the lan-guages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.

So, what the hell is Y? If you're a Java zealot, you might say that it's strong typing and bytecode portability. Of course, a C nazi would want to tear his hair out because of how "limiting" all that strong typing is, and how infernally slow the produced code is. Meanwhile, Python geeks will sing the praises of syntactically signifigant source-code formatting, ML nuts will talk about how nifty it is to have your whole program look like it's written in EBNF, and Perl monks will spout off huge strings of acronyms which all serve to hilight the Swiss Army knife nature of their language.

In other words, by failing to take a stand on what makes some languages better than others (other than the bland assessment that the addition of lexical closures in Perl 5 was a good thing), he succeeds in avoiding offense, but utterly fails to say anything useful. "Power" becomes a catch-all abstraction, like a D&D stat, and nobody gets to argue about what features they actually want in a hypothetical uber-language, because that might get someone's panties in a bunch.

And now I'm grumpy because I stopped to write this out instead of studying for my Distributed Object Programming final tonight. Feh.

While Gnutella's distribution algorithm scales badly, there's no reason a fully distributed system for a finite amount of content can't scale well. Netnews scales fine, for example. Once somebody builds something that caches popular stuff near people who want it, the bandwidth requirement should drop way down. channels to download content.

(This happens to bug me personally because he claims to have been the first to observe that the tragedy of the commons problem applies to Internet congestion. He wasn't; I was, in 1985. See RFC970)

As a previous poster noted, the default with Gnutella is not to share anything. That's why so few share. This isn't rocket science.

This is an old controversy. I was the first to work seriously on Internet congestion and originated packer re-ordering in routers. There was a worry at the time, mostly from some BBN people, that being able to do this was in a sense, evil. Their concern was that as long as nobody could regulate traffic flows, charging for bandwidth wasn't possible. Cheaper bandwidth made most traffic shaping unnecessary, but now and then, when some new application causes a traffic spike, the issue comes back. Over the last 15 years, cheap bandwidth has always won. This will probably continue until everybody has enough for a few channels of streaming HDTV.

Still, Gnutilla is a bandwidth hog. It looks to me like its directory system is an O(N^2) traffic generator, because it uses a flooding algorithm. Somebody needs to fix that. Soon. Directory traffic should be minimal, and content traffic should mostly be local. Most of the traffic is probably on a small fraction of the content, and that can be handled very efficiently if done right. Gnutilla should be using less bandwidth than MP3.com.

• SYN flooding
  The basic problem is that protocol stacks derived from BSD commit substantial resources on the receipt of a SYN packet. That makes them vulnerable to TCP SYN packets with forged source IP addresses. The proper solution is to allocate only a small control block at the LISTEN -> SYN_RCVD transition, and allocate the full resources for a TCP connection only at the SYN_RCVD -> ESTAB transition. In a SYN flood, the connection never gets beyond SYN_RCVD, so this confines the attack to using up these small control blocks.

  The lookup used during SYN_RCVD should be hashed, so it doesn't slow down as the number of connections in that state increases, and the allowed number of connections in SYN_RCVD should be made very large (maybe as big as 100,000) in a large server. This allows for a huge SYN flooding overload without impacting real connections much.

  There's a commercial firewall from Israel that does something like this, but it really should be part of the protocol stack.

• ICMP broadcast floods
  Don't reply to ICMP packets sent to broadcast addresses. This is an out-and-out bug, known for over a decade, and should have been fixed everywhere by now. Vendors that haven't fixed it yet should be subjected to public embarassment, if not litigation.

• HTTP request overload
  This is the tough one - being attacked by a large number of completely valid requests. One answer is to impose fairness by source IP address within the server, so that each source IP address gets equal responsiveness. This fix won't stop the problem, but it will slow it down substantially. It's going to take some new development, but the concept is conceptually similar to fair queuing, which I invented long ago. Most of the same issues apply within a server as apply in a congested router.

Implement all this, and the problem will go from being headline news to a minor nusance. Linux network hackers, get going.

I'm not currently doing protocol implementations, but I'd be glad to talk to anybody working actively on the problem. I did substantial work on TCP/IP in its early days, before going on to other things, so I do know what I'm talking about here.