Subject: RE: internet draft on suggested mod to the Nagle algorithm

From: Vernon Schryver <[email-masked]>
Date: Fri, 5 Feb 1999 11:06:43 -0700 (MST)

> From: Art Shelest <[email-masked]>

> Why not parametrize the Nagle?
>
> Instead of "allow only one unacknowledged segment"
> allow "allow N unacknowledged segments/bytes" and 
> specify recommended range of values.
>
> The N=2 would be similar to current proposal and also
> fix the case where application follows the 
> "small write, small write, read" operation, 
> which is not addressed by the proposed draft.
>
> The N=2 seems like a good choice, because receivers
> typically ACK every other packet.

How would you implement that?  You could record not merely the sequence
numbers of RFC 793 and the one additional sequence number of the draft,
but the starting sequence number of each of the last M segments, where M
is the maximum value of your N.  You'd probably want to record the sequence
numbers corresponding to the starts of application write requests instead
of segments on the wire.  On each write, you'd just cycle the stack of
previous sequence numbers.  For likely values of M, you wouldn't need more
than a couple 100 bytes for every TCB, and they could be maintained and
used with only a few 100 instructions at start, another few 100
instructions on every send.  However, we're not talking about typical
GUI bloatware, where adding cycles to every keystroke does not matter.
TCP/IP can now be done with a few dozen cycles total, so adding such
overhead would not be good.  I don't see how to implement a parameterize
Nagle algorithm in real life.

I am unhappy about the English descriptions of the current and modified
Nagle algorithms in the draft.  As I read it, the English description of
the modified Nagle algorithm is only slightly related to the later concrete
description.  Like talk of a parameterized Nagle scheme, the English in
the draft sounds nice until you try to figure out what it might really
mean, and then you realize it is at best fuzzy.  That is a Bad Thing(tm).
To fix this problem, I would delete the English description of the modified
algorithm and stick to the concrete talk of sequence numbers.

Vernon Schryver    [email-masked]

---

From: Rick Jones <[email-masked]>
Date: Fri, 05 Feb 1999 11:19:10 -0800

Are we arriving at the conclusion/concensus that the problem being
solved here (that a single send of say 1.5MSS bytes encounters a delay
in the second segment) has already been dealt with in a number of
production TCP stacks by interpreting Nagle on a "send" rather than a
"segment" basis? And that a pair of 0.75 MSS sends would still encounter
the "son of Nagle" interaction?

rick jones

PS where can I find the original "chapter and verse" on Nagle?

PPS - As this thread continues, I've been in contact with one person who
inherited an application that disable Nagle, but did not know why, nor
what the Nagle algorithm was. So, as part of "outreach" :) I wnt through
the 30 second descrition of what it did and how buggy applications might
interact with it and the ACK policies - he seems very pleased to learn
what was going on and thought he could remove the call. Is that perhaps
the root problem here - that people are writing apps without
understanding? 

I'm guessing that with the possible exception of a very small number of
applications (small, streaming transactions?), the disabling of Nagle is
really just a kludge, and that the networks as a whole would be best-off
if we got the applications fixed? If they were going to adopt the
secondary flush proposal in the RFC there would need to be app changes
anyway... so we are talking about doing outreach with the apps types
either way.

-- 
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, or post, but please do not do both...
my email address is raj in the cup.hp.com domain...

---

From: [email-masked]
Date: Fri, 5 Feb 1999 16:26:49 -0500

> PS where can I find the original "chapter and verse" on Nagle?
RFC 896 (the original RFC on the Nagle algorithm) says:

 The solution is to inhibit the sending of new TCP  segments  when
 new  outgoing  data  arrives  from  the  user  if  any previously
 transmitted data on the connection remains unacknowledged.   This
 inhibition  is  to be unconditional; no timers, tests for size of
 data received, or other conditions are required.   Implementation
 typically requires one or two lines inside a TCP program.

RFC 1122 (Host Requirements) says:

 If there is unacknowledged data (i.e., SND.NXT >
 SND.UNA), then the sending TCP buffers all user
 data (regardless of the PSH bit), until the
 outstanding data has been acknowledged or until
 the TCP can send a full-sized segment (Eff.snd.MSS
 bytes; see Section 4.2.2.6).

As we have seen, many implementations honor neither of these.
I don't know of any other RFC citations. Anyone?

Jon Snader

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 5 Feb 1999 15:35:58 -0800 (PST)

> the "son of Nagle" interaction?

I don't think there is a concensus.  First, the proposed change is not on a
per-send basis.  Please refer to Greg's latest mail why he did not like
this idea.  It seems to me, correct me if I am wrong, Greg is trying to
tackle it in the context of TCP, which looks at segment size and data
available to be sent only.  And for BSD derived implementations, Dave pointed
out the sosend() problem to be fixed first.

							K. Poon.
							[email-masked]