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

From: Vernon Schryver <[email-masked]>
Date: Fri, 12 Feb 1999 21:12:03 -0700 (MST)

> From: Greg Minshall <[email-masked]>
 
> > for changing the Nagle algorithm.  Could someone review the plausible
> > scenarios where the change helps?  (I.e. not just switching the
> > interpretation of "send" from what it seems no one used to something
> > closer to what everyone is doing.)
>
>The scenario is that TCP has been willing to send lots of data because (either
>at tcp_output() or at send()) it was presented with "lots" of data to send (>=
> MSS), and so has sent lots of data.  Now, it is presented (either at
> tcp_output() or at send()) with a "little bit" of data.  In this case, TCP
> will wait until all the previous data has been acknowledged.
>
> (The change would allow TCP to transmit this "little bit" of data (but not
>transmit any subsequent "little bit" of data until *this* "little bit" of data 
> has been acknowledged.)

That's toward answering my question, but doesn't quite hit it.
First, could we forget the "at tcp_output()" clause since it seems everyone
agrees that the original RFC 896 text, the RFC 1122 text, and common
implementations want the delaying to happen only at send() and many
implementaitons come pretty close to achieving that?  To the extent that
some do not achieve that, it might be worthwhile to write something,
probably in the 'common bugs' RFC.
  
Second, could we please have something to make the bad scenario compelling?
For me, that means either a convincing argument that significantly many
well written applications (no write-write junk) suffer the problem, or a
pointer to a real application that exemplifies the class of suffering
applications.  These must be applications that now suffer unnecessary
latency on real world TCP stacks on private nets or the Internet.
(Statements like "this code would have problems if it did something other
than what it does" are inadmissable.)

Statements like "my intuition says there must be lots of code that writes
1700 bytes with MSS=1460 on a system that worries about tcp_output() but
not send()" are not convincing.  My intuition says that most applications
uses stacks that watch send() (or won't be fixed so this is all moot), or
either write less than an MSS or so much more than an MSS that they hit
windows, or would have to use TCP_NODELAY regardless of Nagle
modifications.

Good design changes depend on a kind of Occam's Razor says that in the
absense of objective evidence, the 'gut feeling' that supports the
status quo is always right.
 ________________________________
 
] From: Kacheong Poon <[email-masked]>

] ...
] 1. There is a bad interaction between some applications, e.g. transaction
] type applications, and Nagle algorithm.

We have only hypothetical applications that suffer bad interactions.

] ...
] 4. Many TCP stacks already have some form of modified Nagle algorithm.  The
] interesting thing is that most people do not know about that.  And since
] there is no "standard" modified Nagle, application programmers cannot rely
] on this fact if they want their applications to run well on multiple
] platforms.  Thus having a modified Nagle algorithm does not help reduce
] the number of applications setting TCP_NODELAY.

As far as I can tell, much of the so called "modification" consists of
doing what RFC 896 actually says instead of what some people thought it
said, namely delaying by send() instead of tcp_ouptut().  It's not clear
"do what RFC 896 says instead of what we thought it says" needs to be
published, except perhaps in the 'common bugs' RFC.

] Because of 3, Greg and many others thought that we should find a way to 
] remedy 2.  And many such applications are like 1. ...

The assertion that there are many applications that would benefit has been
repeated many times.  Maybe I've been made cynical by politicians, each
repetition of an unsupported claim convinces me more of the opposite.
Again, please name or compellingly describe an application that is well
written (e.g. uses writev() or WSASend()), suffers undesirable latencies,
and would be helped by a change to the Nagle algorithm, as the Nagle
algorithm is defined in RFC 896 and widely implemented.

] ...
] My observation is that Vernon, and maybe others, think that there is no
] problem at all.  It is just a problem of incompetent programmers and IETF
] should not do anything about it.  Rick and others think that we should
] document the modified Nagle many stacks also have, namely doing the check
] on a per-send basis.  This helps 4.  And to further reduce the problem set
] of bad interactions, we should investigate EPS.  Have I misunderstood the
] flow of discussions so far?

That overstates my view--I could be easily convinced the problem exists
by other than repetitions of unsupported claims.  The availability of
NODELAY may make finding an exemplar difficult.  However, I'd be glad to
hear of a real application that could stop using NODELAY thanks to a
modified Nagle.

] ...
] You have been involved with IETF much longer than I do.  I guess I have
] misunderstood the intention of FYI notes and various other infomational
] documents IETF has published...  Is IETF really only a "standards committee?"
] Maybe you can tell me what those documents are for.  In your opinion, do
] many of them also fall into the category of textbooks and IETF should not
] have published them in the first place?  I guess probably.

Yes, the IETF is merely a standards committee.  Standards committees have
many people who feel more publish-or-perish pressure than the canonical
academic.  The FYI's and "various other infomational documents" (presumably
the Informational RFC's, since the IETF only publishes RFCs, some of which
also get the FYI label) are generally not the most admired, admirable,
and/or influential documents from the IETF.  Some are of only trade rag
quality, between just plain wrong and painfully naive.

] My point is that it seems that so far no textbook has been clear on what Nagle
] algorithm is and its implication.  Maybe textbook authors do not care, or
] people designing protocol do not care to tell them about it, or ...  IMHO, a
] brief document from TCP implementors urging people not to disable the
] algorithm by default  and describing the right way to write network programs
] using TCP is another way to tackle the problem the draft tries to solve, but
] without modifying Nagle algorithm.  And it will carry more credits than from
] any textbook.

To paraphrase, you want to use the bully pulpit of the IETF to preach
about something we agree is bad.  You figure that an RFC would be influence
more people, be more authoritative, and more effectively fix the problem
than a textbook.

I've had this argument many times over the years with people who want to
write mini-textbook RFC's.  Since I first took my position, I've seen too
many poor informational RFC's published.   I've also seen (and written)
countless words about subjects like the Nagle problem (including the Nagle
problem) in forums more widely read than the RFC archives (e.g.
mailinglists and netnews).  The problems go one.  If RFC 896 didn't fix
it, then your RFC 3999 won't either.  The best and most effective thing
you might do to fix the Nagle problem is to help/convince the big TCP
textbook authors to produce revised editions.  (By "Nagle problem", I mean
junk code that does unncessary tiny_write-tiny_write or necessary
write-write but does not know about Nagle.)  I offer RFC 896 and those
#$%*@! textbooks and trade rag idiots that say that Ethernet is limited
to 37% as proofs.

I've seen a very little, merely second hand, of what it costs and profits
an author to write a real textbook.  That has convinced me the real thing
too much like hard labor for my tastes, and made me a little cynical about
the common ambition to spend a few hours and whip out a mini-textbook RFC.
   ________________

] From: Greg Minshall <[email-masked]>

] ...
] > One thought that just struck me is that we've all been bantering about
] > with a 1460 MSS thinking primarily about 1500 byte MTU networks and how
] > 4096 is big enough for a 1500 byte MTU network and all that.
]
] While i don't think it is reasonable to assume that an application tracks the 
] actual MSS (given path MTU, etc.), i think it *is* reasonable that an 
] application know *something* (such as the largest MTU on a connected, 
] non-loopback interface).

I think that's asking too much of applications, what with mulitihoming,
dynamic routing, the difficulties in finding the MTU's of all currently
active interfaces on some platforms, and interfaces that come and go
(e.g. SLIP and PPP).

Vernon Schryver    [email-masked]

---

From: Greg Minshall <[email-masked]>
Date: Tue, 16 Feb 1999 18:00:02 -0800

Vernon,

> Second, could we please have something to make the bad scenario
> compelling? For me, that means either a convincing argument that
> significantly many well written applications (no write-write junk)
> suffer the problem, or a pointer to a real application that
> exemplifies the class of suffering applications.  These must be
> applications that now suffer unnecessary latency on real world TCP
> stacks on private nets or the Internet. 

I'm not sure we're converging, but let's try this:  for request-reponse 
protocols with variable-sized responses, with the current Nagle and delayed 
ACKs, there is no way to write the server application such that some 
percentage of the responses don't get delayed.  The modified Nagle allows an 
application writer to write their application to avoid that particular delay.

Here's something i mentioned to the Rick Jones (and the list); maybe this 
helps:

> Check out, for example, John Heideman's article in the  April, 1997,
> ACM SIGCOMM Computer Communications Review, or Henrik Nielsen, et  al,
> from SIGCOMM 1997, for example of fairly well-crafted applications
> that  still run afoul of Nagle/delayed ACK interactions.

Greg