> For quite some time (I observed this in the summer too, but figured
> it would go away), -current TCP has been performing very badly for
> short file transfers.  [...]  You'll note that the second packet
> [from server to client] is not MTU-sized - this causes the receiver
> to not send an ack immediately.

Isn't this what slow-start is all about?  Start with small packets and
ramp up?

> This has a pretty serious performance impact.  It means that a short
> TCP session transferring 2000+ bytes on local network or the loopback
> interface takes a couple hundred milliseconds, rather than a couple
> milliseconds.  It means that NetBSD is horrible for webservers.

Perhaps slow-start needs to be rethought in view of WWW, which I think
is probably the first protocol to carry on a lot of TCP conversations
sequentially, sending only small amounts of data over each one.

Personally, I think a preferable solution would be to redo the WWW
protocol so it doesn't keep tearing down connections and creating new
ones, precisely because connection setup and destruction has high
overhead.  Slow-start just aggravates this by increasing the effective
connection-setup overhead.  (To be sure, slow-start has its benefits,
but they don't kick in in these cases.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu