and that's what happened even with nagle enabled?

that's one reason i asked about the source of the ``vast majority''
of packets on the net.  if they are as you say, then i can't see nagle
being invoked by any of those applications.   they already do their
own buffering (i was looking at the code for them just now).
ftp for instance writes in blocks of 4k (it's fairly old code) and
others do better than that.  that's much larger than the
typical MSS (which is indeed rather smaller than 4k), so the
nagle delay will do sod all.   as the rfc defines it, it isn't invoked,
except for the FTP requests, which are small,
and then all it does is delay them pointlessly, since nothing
will be added to those!

there is buffering in the tcp/ip implementation,
so concurrency isn't affected by the mismatch
between MSS and write buffer size.   (ie, ftp can dump its 4k and read
the next block of the file whilst the previous ones are going out.)
same for http.  does apache dribble the bytes out in titchy quantities?

the second point is that the MSS provided by TCP/IP, if based only on
the host interface's MTU configuration, isn't sufficient anyway.  path
MTU discovery could be used i suppose except that it was added in retrospect,
relies too much on routers, gateways and firewalls all behaving well,
all the way there, and even then there are non-trivial problems
with it and tcp/ip.