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

From: Art Shelest <[email-masked]>
Date: Fri, 5 Feb 1999 08:16:04 -0800

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.

-----Original Message-----
From: Kacheong Poon [mailto:[email-masked]]
Sent: Thursday, February 04, 1999 6:34 PM
To: [email-masked]
Subject: Re: internet draft on suggested mod to the Nagle algorithm

> This is at least one extra send operation, which can't be a good thing,
> particularly when the network is over-utilized (or near to it) already.
> While this isn't as bad as Rick's example (1461-byte writes), it is
> still bad utilization. (I'd hate to own the network that did both.)

Let's look at the problem from an application programmer's point of view.
You
are writing a network application, the transfer pattern can be anything. You
notice a performance problem and find that by disabling Nagle algorithm, the
problem goes away.  What will you do in the production code?

Now with the changed Nagle algorithm, for certain kind of transfer pattern,
you do not notice any performance problem.  So you will not turn off Nagle
algorithm.  But in fact, the Nagle algorithm may still kick in sometimes and
help the network.  Just that you only see the little impact from time to
time.

Nagle algorithm helps a lot in the case of telnet like traffic.  This we
should not change.  But for some kind of transfer pattern, it helps a lot if
we relax the algorithm.  By doing this, we encourage  application programmer
not to disable the algorithm.  IMHO, this is what the  proposed draft is
about.  We do not want the algorithm to be disabled in general.  We are
making
an incentive for programmers not to do that.  At the same time, we do not
adversely affect the network.  Imagine what will happen if every application
programmers disable the algorithm "by default."

> I'd say that based on this info, it is better to just disable Nagle if
> your application is going to be writing small (1.5 segments) chunks, and
> leaving it enabled for applications that do large writes, rather than
> introducing lots of new frames to the network.

The problem is an application can turn the algorithm off any time,
regardless
of the transfer pattern.  And the proposed change is not to disable the
algorithm, but to relax it in some cases.  I'd rather see a slight increase
of network traffic in some cases than have most applications turn off the
algorithm by default.

Solaris's TCP stack has some form of the proposed change for many years.  I
have not heard of customer complaints because of it.  At the very least,
there was no network meltdown...

							K. Poon.
							[email-masked]

---

From: Greg Minshall <[email-masked]>
Date: Fri, 05 Feb 1999 11:47:17 -0800

Art,

> specify recommended range of values.

Mainly, i think, because there doesn't seem to be any need to do this.  Using 
the current or modified Nagle works for almost all applications.  Disabling 
Nagle may be required for a very small set of applications.

Greg Minshall