Subject: Re: Strange Nagle effect on 1.6.2
To: Alan Barrett <apb@cequrux.com>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-net
Date: 05/30/2005 12:21:19
In message <20050530185216.GC2111@apb-laptoy.apb.alt.za>,
Alan Barrett writes:

>On Mon, 30 May 2005, David Laight wrote:
>> No data outstanding, to nagle lets the last fragment out.
>> 
>> > 13 642.856484 SRC.30010 > DEST.63394: P 397222:398512(1290) ack 1 win
>> > 17520 <...>
>
>If the immediate sending implied by the TCP PSH flag took precedence
>over the delated sending implied by the Nagle algorithm, then this
>problem would not arise.  Is there any reason not to let the PSH flag
>take precedence?

Yes: RFC-1122 discusses the use of PSH with Nagle, and says not to do
as you suggest.

John Nagle developed the heuristic in RFC-896 specifically for
interactive Telnet. In such usage, single-keystroke input can and will
generate single TCP-stream writes with the TCP PSH bit set.  Thus,
blindly following PSH (which is what I think you suggest) would defeat
the intent.

RFC-1122 section 4.2.3.4 (p.98) says:

         4.2.3.4  When to Send Data

            A TCP MUST include a SWS avoidance algorithm in the sender.

            A TCP SHOULD implement the Nagle Algorithm [TCP:9] to
            coalesce short segments.  However, there MUST be a way for
            an application to disable the Nagle algorithm on an
            individual connection.  In all cases, sending data is also
            subject to the limitation imposed by the Slow Start
            algorithm (Section 4.2.2.15).


qThe immediately-following DISCUSSION: in in RFC-1122 discusses
implementation issues. The list of four conditions to send on p. 99.
lists PSH under condition 2, viz:

                 (2)  or if the data is pushed and all queued data can
                      be sent now, i.e., if:

                          [SND.NXT = SND.UNA and] PUSHED and D <= U

                      (the bracketed condition is imposed by the Nagle
                      algorithm);

(where D is data available, U is usable window.)

In other words, a heuristic similar to what you sugges is already
called out in RFC-1122; but can be applied _only_ when the connection
also has no unacknowledged data outstanding, and the pending data is
smaller than the window. The "no unacknowledged data" condition is, I
think, not met by Stuart Brooks' trace.