Cell Relay Archive

[raj@cup.hp.com (Rick Jones)]

Vernon Schryver (vjs@calcite.rhyolite.com) wrote:
: - the original questioner said the TCP_NODELAY helped whatever was
: 	being done, which suggests the involvment of an application
: 	that has not bee designed with an eye to on-the-wire traffic,
: 	something that the Nagle algorithm hurts.

I think that maybe it si time to re-visit the Nagle algorithm. When it
was first proposed, I'm *guessing* that there was essentially one
common TCP MSS (Ethenret's?) and it was relatively small. So basing
the send decision (in part) on the size of the send relative to the
MSS was pretty well a fixed decision point that apps could code to if
needed.

Today, we have a plethora of MSS's out there - Ethernet, Token Ring,
FDDI, ATM, Fibre Channel, ad nauseum. Moving a fixed application
among these networks means that it is moving through a wide range of
MSS values, and the one value it picked will almost certainly be
wrong.

What if... (can't work for HP unless you say that from time to time :)
instead of working off of the MSS, which varies, the send decision
worked off of the header (which varies less) - that is to say, the
send/wait decision would be based on the ratio of the send size to the
size of the TCP header?  That way, we could say that you always send
when efficiency (from TCP's standpoint) is > 88% or some other value.

I think that this is better than the alternative I've heard requested
by folks emailing me on performance questions - enabling immediate
ACK's... I've even heard (unsubstatiated) that one "latest, hottest
thing" in OSes from the Pacific Northwest may be doing this already.

rick jones