andrewf@syacus.acus.oz.au (Andrew Friedman) (05/27/91)
Hi, I've been following the thread with some interest and would like to make a few remarks. I should make a disclaimer straight away, I am a TCP/IP novice, and spend most of my days working with the OSI suite of protocols. No doubt you'll tell me where I'm wrong, maybe you'll be kind enough to tell me where I'm right. I'm not sure if anybody has mentioned that the Nagle algorithm will interact particularly badly with a remote host when a key stroke isn't echoed (such as the keystroke under question) and the host delays sending acknowledgements (according to the BSD daemon book, BSD delays acknowledgements). So changing the application to send a character sequence with no effect e.g. a null will force the acknowledgement out much sooner. Of course, this won't help when the network itself is misbehaving. The above assumes that the Telnet client forwards every character as soon as it is written. If the client is perhaps smarter (and from Leo McLauglin's posting I assume BSD Telnet clients aren't smarter) and wants to reduce network load it might collect characters using a short timeout, but also forward collected characters after reading a forwarding character, e.g. an control character, like ESC. Again, the sequence is split, but Nagle is not to blame. The Telnet shouldn't have been clever about forwarding on control chars, or should it? If this is the case, than I don't know what could be easily done, perhaps the the client might allow you to change the forwarding chars. I can think of one realistic place where this situation might arise, somebody out in X.25 land, with an X.3 terminal session gatewayed to a Telnet session. At least on a PAD forwarding characteristics are always alterable. Michael and others suggest that Telnet clients treat escape sequences specially, and/or disable Nagle, but that doesn't help those people who need to distinquish between an ALT-F COKEBOTTLE and an ALT-F. I think a character collection period with a small-timeout inside Telnet would be a more general solution. This better behaved Telnet might be entitled to use a connection without being subject to Nagling, but it wouldn't really matter. Actually, I doubt that at the speed I type at, Nagling makes any difference, and I wonder if Nagles algorithm is more intended for applications that abuse the network with lots of small packets rather than fingers. When Nagle's algorithm was first mentioned in this thread. I was against it. I said to myself, how can that naughty Nagle delay sending a packet, when the TCP/IP user has done a PUSH. Later, reading the daemon book, I discovered BSD doesn't implement PUSH bit, (not even to the extent required by RFC1122?), so every write from the TCP/IP user will go to the network (flow control willing) in the absense of Nagle. If BSD had a user controllable PUSH Nagle wouldn't be nearly as needed. But that would flaw the programming paradigm, you can't flush file descriptors only file pointers. Eventually, I decided, that even PUSHed packets should be Nagled, because the network needs all the help it can get but a bound of timeout comparable to the average round trip time, rather than having to wait for a delayed ack. Of course the real problem is that networks are pretty lousy for applications sensitive to delay, and timing. Somebody want to do a P.D. NeWS? Thanks for listening, Andrew Internet: andrewf@syacus.acus.oz.au ACSnet: andrewf@syacus.acus.oz