"Perry E. Metzger" <perry@piermont.com> writes:

> > Maybe adding TCP_NODELAY to telnet will fix:
> > 
> >   http://mail-index.netbsd.org/netbsd-users/2003/06/12/0001.html
> 
> Except it shouldn't. I think Nagle's algorithm only delays things if
> there is unack'ed data outstanding. IF there is no unacked data
> I believe Nagle's algorithm sends immediately.
> 
> If TCP_NODELAYs actually fixes this and other things maybe we have a
> bug that we're just masking.

There's a well known problem when Nagle's algorithm is combined with
delayed ACKs, as happens with many modern TCP stacks.  A sends a small
packet.  B receives it.  B then applies the delayed ack algorithm, in
which the ack is delayed for 200ms in the hopes that the receiving
application will generate a reply.  In the meantime, A queues up
another small packet, but it isn't sent because Nagle's algorithm
delays it.  After 200ms B releases the ACK, A receives the ACK, and
sends the queued up data.

Here's a discussion of the issue I found using Google:
    http://lists.w3.org/Archives/Public/ietf-discuss/1998Dec/0025.html

It would clearly be wrong for telnet to turn off Nagle's algorithm.
Nagle's algorithm was basically designed for telnet, to prevent each
character typed from generating a new packet.

However, there is clearly a bad interaction.  I suppose one
possibility would be to not delay the ACK of a small packet.  Or a
more cautious approach would be to add a new option, similar to
TCP_NODELAY, which would mean ``do not use delayed acks.''  This would
then be set by any application which expected to receive packets of
data for which it would not generate an immediate reply.  I think it
would be appropriate for telnetd to set that option, fixing the
nethack problem.

Ian