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

From: Vernon Schryver <[email-masked]>
Date: Thu, 11 Feb 1999 22:37:12 -0700 (MST)

> From: Kacheong Poon <[email-masked]>

> Just for an exercise, suppose TCP does not delay an ack for a segment smaller
> than MSS size if the segment received prior to that is a full MSS size
> segment.  It still uses the current delay ack strategy for full MSS size
> segments.  Will this solve the problem we are discussing when combined with
> the Nagle modification on a per-send basis?

Which Nagle modification is that?  The algorithm as classically described
and widely implemented that mostly worries about application send requests
instead of packets?  Or the new proposal with its intentional (and I think
undesirable) ambiguity between application requests and packets?

> For telnet like traffic, TCP delays ack the same way as before.  For
> request/response traffic, it will not delay ack for the last small segment. 
> ...

Assuming there is a problem here that needs to be solved, and that the
problem cannot be easily and cleanly solved with an explicit flush bit,
then I think that's a good area to investigate.  The old delayed Ack is
a badly aimed hammer that has mashed a lot of thumbs over the years.
(E.g. the 10X performance hit taken by some commercial UNIX systems
talking to some version of Sun's system.)

> This should be easy to implement, much easier than an adaptive delay ack
> algorithm.  Will Vernon consider this as a bloat to OS?  Are those extra
> acks in some situations acceptable to people on this list?  Note that this
> is just an exercise on thinking what delay ack strategy should be.

Maybe.

First we need some evidence of a problem that needs to be and can be
solved, other than the familiar committee need to Publish Something. 
I suspect there is real problem, but so far, there is no clear evidence.
As far as I can recall, all of the proposed examples of problems that
could only be solved with the various proposals have failed.
It's hard to invent a solution to an unknown problem.

The HTTP/1.1 problem is interesting, but I suspect it has already been
solved with NODELAY, smart use of select(), and so forth.  A handicap for
any new idea is that it will not be widely implemented for a long time.
Good programmers must and will continue to use the old solutions.  If
you're writing portable code, if on some platforms you must use NODELAY,
and if NODELAY always works as well as the new scheme, do you bloat your
code with #ifdef's or runtime bytes to use the new scheme?  Or do you just
use NODELAY and forget the new mechanism?

} From: Kacheong Poon <[email-masked]>

} ...
} Yes, I have read the 2 RFCs.  The reason I suggested a draft on describing the
} preferred way to write network application is that many application
} programmers do not really understand how TCP works.  Reading those RFCs may 
} just confuse them more, as those RFC assumes an understanding of how TCP
} works.  And those RFCs do not provide a programming guide line.  By guide line
} I mean actual example code.  To me, a document with example code and an
} intuitive explanation on why the code is better in simple networking terms
} is more suitable for most programmers.  I don't know if there is such a
} document freely available on the Web.  If you know, please post a reference.

A document that would teach good programming sounds like a good thing.
Such documents are often called textbooks.  Some good textbooks contain
lots of example code.  However, as you basically say about the old RFCs,
the IETF is not in the introductory** textbook business.  The IETF is a
standards committee, not Addison-Wesley, John Wiley, or even The Microsoft
Press.  Writing, printing, and distributing good textbooks is hard work.
Textbook authors and publishers should be properly paid.  Regardless of
anyone's intentions, I doubt that the profits for an RFC can buy more than
the usual trade rag consutant blabbler and inter-ad filler, which is
usually wrong, and always much less reliable than the ads.

**The technical issue is basic, no matter how many lazy people get it
wrong.  As I said earlier about why fwrite()/stdio was invented--everyone
competant knows that extra I/O requests are bad, whether on wires or to
disks.  Would you feel good about hiring a programmer whose code does
unnecessary multiple database access?--of course not, if you've ever heard
about locking, commits, concurrency, disk latency, and so forth.
The small TCP write problem is very much like writing single disk sectors
instead of whole tracks or cylinders

] From: Rick Jones <[email-masked]>

] ...
] Would a PTMU smaller than the MSS interfere with the receiver's ability
] to tell a full-sized segment from a small one? Especially in a
] unidirectional case, or an assymetric route case.

It might be good enough to consider anything bigger than 512 bytes full
size, and any segment smaller than its immediate predecessor.  Not that
I'm advocating anything--just speculating.

] ...
] Well, it is my belief that "today" an ACK costs just as many CPU cycles
] as a data segment.

As Rick knows, I mostly agree with that.
But the current issue is not CPU cycles, but 100 ms request-response latency.

Vernon Schryver    [email-masked]

---

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

> Which Nagle modification is that?  The algorithm as classically described

I guess the phrase "on a per-send basis" is not clear enough...

...

Let's see if we can agree on what the problem the draft tries to solve.
Greg and others can comment on this if I mistake.  I observe the following
points so far.

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

2. We have observed that many network applications set TCP_NODELAY flag by
default, thus disabling Nagle algorithm, even though it may not be necessary.
Many application programmers are not aware of the implications of setting
TCP_NODELAY flag and do not understand Nagle algorithm.  But by setting
TCP_NODELAY flag, they see their applications run better.

3. In many circumstances, Nagle algorithm helps reduce unnecessary network
traffic.

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.

Because of 3, Greg and many others thought that we should find a way to 
remedy 2.  And many such applications are like 1.  So Greg wrote the draft
to solve 1 hoping 2 will go away.  Note that the draft does not intend to
solve all bad interactions in 1.  But by getting rid of the most common set
of bad interactions, 2 may go away.

Do we agree on the above points?  If we do, the question comes to if modifying
Nagle algorithm helps.  And if by setting a "standard" modified Nagle, can
application programmers rely on this fact and do not need to set TCP_NODELAY
flag even if their applications run on multiple platforms, thus eliminating 4. 
Does the proposed algorithm really get rid of the most common set of bad
interactions?  Or do we only need to have an EPS mechanism, as described in
the draft?

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?

> standards committee, not Addison-Wesley, John Wiley, or even The Microsoft
  ^^^^^^^^^^^^^^^^^^^

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.

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.

							K. Poon.
							[email-masked]