In message <04ef01c565b3$4b038380$5e22a8c0@STU95>"Stuart Brooks" writes
>> In other words, a heuristic similar to what you sugges is already
>> called out in RFC-1122; but can be applied _only_ when the connection
>> also has no unacknowledged data outstanding, and the pending data is
>> smaller than the window. The "no unacknowledged data" condition is, I
>> think, not met by Stuart Brooks' trace.
>
>That seems right to me. My original understanding of the Nagle algorithm
>was that at any one time only a single unacknowledged small segment
>would be allowed on the network. This came from Stevens TCP Vol 1
>(19.4). Having read RFC 1122 it appears that is not entirely accurate.
>Needing to wait for all data to be acked before sending the final packet
>means I am being held up by a delayed ack? 

I beleive so: iirc, that's what David Laight's segment-by-segment
analysis showed.  (It's what I'd expect in any case).

>And since my data is
>predominantly uni-directional I don't see this going away in a hurry.

If your mostly-unidirectional data is RPC-like --- a large "request"
followed by a small "response", or vice-versa --- then I think you
should just turn off Nagle.


>I guess disabling Nagle is an option but, as the traffic, bandwidth and
>delay characterstics of my link can vary widely, I don't think this is a
>great idea. I suppose I could dynamically enable/disable Nagle depending
>on the prevailing conditions. Can anyone see any potential problems with
>doing that? 

Seems to me like more trouble than it's worth. X11, Samba,
NFS-over-TCP, all just disable Nagle.


>der Mouse's idea of a flag in send() is quite attractive.

Hmm. Yes, but it's yet another incompatibility...  TCP and OSes have
gotten by for 20-odd years with no good way for applications to send
PSH to their sending TCP.