> 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?  And since my data is
predominantly uni-directional I don't see this going away in a hurry.

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? der Mouse's idea of a flag in send() is quite attractive.

Thanks for the help,
 Stuart