Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!lll-lcc!rwolski From: rwolski@lll-lcc.UUCP (Richard Wolski) Newsgroups: comp.protocols.tcp-ip Subject: Re: Nagle algo. in Unix-TCP Summary: John Fletcher, the author of the "troublesome" RPC package replies. Keywords: tcp tinygram RPC X11 Message-ID: <2598@lll-lcc.UUCP> Date: 13 Sep 89 15:09:03 GMT References: <2581@lll-lcc.UUCP> <13394@well.UUCP> Organization: Lawrence Livermore Labs, LCC, Livermore Ca Lines: 105 Hello one last time. Some time ago I posted a request for information about the Nagle algorithms included in various flavors of Unix and got a rather surprising response from John Nagle himself. As I indicated in my previous posting, my questions regarded an RPC system that a colleague of mine had written which sent messages each in two "send" calls (instead of one which we now know is the accepted Unix method). After returning from vacation and reading the various correspondence in which I had been engaging, he felt compelled to contribute his thoughts, but unfortunately does not have access to a machine which gets a news feed. I am, therefore, posting this reply on his behalf in an objective manner as possible. Rich Wolski P.S. Please reply directly to John Fletcher as I don't relish the prospect of intercepting scores of nasty-grams. ------------------------------------------------------------------------------- In article Article 8533 of comp.protocols.tcp-ip John Nagle writes: > What seems to have happened here is that several mechanisms in TCP >are interacting with a strange kind of application to produce poor performance. > > First, "silly window syndrome" is irrelevant here. Silly window >syndrome occurs when the window is full most of the time, but here, >we have the tinygram problem, which occurs when the window is empty most >of the time. It's a common misconception that the two problems are the >same. They are not. They are handled by separate code in the UNIX >implementation, incidentally. . . . >But here, we have someone who is trying something that has the property >that it does > > SEND > SEND > wait for reply. > >This doesn't take turns the way a typical transaction protocol does, so >the guesses built into TCP are bad for this situation. . . . >TCP is trying to protect the network from dumb applications. We fixed it >back in 1985 so that when the application is dumb, the application suffers, >not the network. We have here a dumb application layer. John Fletcher (the author of a locally designed RPC package) replies: My colleague Rich Wolski recently inquired over the net in regard to the poor performance of TCP sockets when the typical behavior was alternately to send two buffers and then to receive two similar buffers. A rate of ten buffer pairs per second was obtained. As I understand it, the second buffer in a pair was not actually sent by the interface until the first was acknowledged, and that acknowledgement was delayed. The responses he received were not very helpful. The most detailed one suggested using library calls that would copy the two buffers into one, an overhead that we are seeking to avoid. It also described the behavior of the application as "dumb" and therefore presumably not deserving of adequate support; this approach, if extended more broadly, could put us all out of work. On our own we found that the difficulty was avoided by using the "sendmsg" call to send the two buffers in one call rather than using two "send" calls, one for each buffer. Later, one correspondent suggested the same. Wolski's more fundamental question remains unanswered: What exactly is the model of TCP socket communication that the applications programmer should have in his mind, such that he can correctly determine the most appropriate way to achieve his purposes? Is there such a model, and is it machine- independent so that portable yet efficient programs can be written? It was mainly our experience as systems programmers, who have implemented communication systems of our own, that lead us to suspect that "sendmsg" _might_ consolidate multiple buffers into one packet and that one packet _might_ fare better than more. The typical applications programmer has likely never heard of packets; to him the choice of one "sendmsg" vs. many "sends" is mainly one of programming convenience, which might well come down in favor of the latter. In fact, in our case the multiple "send" approach yields the shortest, cleanest program. My own suspicion is that there is no clear model, because in general I find that such is characteristic of Unix. I was raised as a physicist and therefore always carry the hope that the rule of parsimony will apply; Learn a few universal rules, and derive all else from them. I am almost prepared to believe that Unix and its milieu are the exact opposite: No matter how many rules you learn, there is always one more, and it will affect the next thing that you do. John Fletcher fletch@ocfmail.ocf.llnl.gov P.O. Box 808, L-60 Livermore, CA. 94550