Cell Relay Archive

[vjs@calcite.rhyolite.com (Vernon Schryver)]

In article <3nk2fg$ec4@usenet.srv.cis.pitt.edu> fahad@cs.pitt.edu (Fahad A Hoymany) writes:
>Rick Jones (raj@cup.hp.com) wrote:
>
>: 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
>
>  Ethernet's MTU is 1500 bytes which is relatively large.
>
>: 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.
>
>  The MSS value is based on the smaller of the two MSS's advertized by
>  the two ends.

I'm sure Rick knows about the MSS option.

>                When connection is established a smaller MSS may be
>  used if fragmentation occurs.

Not quite.  The MSS used is the minimum of the two, regradless of
any considerations of fragmentation.  Of course, one of the reasons
for negotiating the MSS is to avoid fragmentation, but you do the
negotiating and use the negotiated value without noticing whether
fragmentation would otherwise occur.


>: 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 am not sure I undestand what you are trying to do here. The MSS has
>   nothing to do with the window size. It is used, though, for the slow 
>   start window, but that's a different story.
>
>: 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.

I think he's talking about the send-without-receiving-an-ACK-when-you-
have-lots-of-waiting-datay decision.  Check the references to "Transmitter
Silly Window Syndrome Avoidance."

Until recently few application used the setsockopts to adjust the receive
window or the send buffer size.  With bandwidths products being other
than only 100 KByte/sec (VAX 780 running 4.1c over Ethernet) or < 5
KByte/sec but > 3 KByte/sec (ARPANET), we now have bandwidth*delay
products with much greater ranges.  Many applications now use the socket
buffer setsockopts.

Why not change NO_DELAY from a boolean to a variable that tunes the
Nagle algorithm?  Most ill behaved applications will still be those that
like do things like {write(5); write(5); read(5)} and will want the the
algorithm off entirely.  Are there others that are not quite so
pathological and could use a fancier setsockopt()?

yeah, its probably not worth it.  Any application that is really using
high bandwidth*delay networks and not bunching its writes is going to
have other, bigger problems than the Nagle algorithm.


Vernon Schryver    vjs@rhyolite.com