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

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

Vernon Schryver wrote:

> Do we agree that I misread the following or it was not tightly phrased?
> I read it as a proposal for letting the application vary the value of N
> from 1 to some large number.

Requiring implementation to be configurable is stronger requirement
than what I had in mind. The wording should have been: "Hosts MUST implement
Nagle(N) where N may be one of the following values...". The configurability
is optional, of course.

> This idea would effectively turn off Nagle for the most common (in my
> experience) bad code, which loves write-write-read-write-write-read....
> It would double the number of packets on the wire for such bad
> applications.  I think that would be Not Good.  Would relaxing Nagle for
> 2 send requests be much different from turning it off entirely?

In the case above, present or draft-proposed Nagle will both generate 2
packets because first will be sent immediately. The performance, however,
will improve from 2 packets per 200ms to 2 packets per RTT (10+ times on
many LANs)

I don't agree with notion that W-W-R applications come from bad programmers,
application programmer should not be required a TCP expert when they simply
treat
socket as a file handle. For all they know, it may or may not be a network
device.
If W-W-R works well with fwrite, why shouldn't it work with send?

Large sends is a more complex case. Both Nagle(2) and modified Nagle will
create 
extra packets with sends slightly bigger than MSS, which is bad for bulk
transfers, 
but good for interactive operations.

It almost sounds like Nagle needs it's own timer rather than being driven by
receiver's delayed ACK timer or RTT. This way, Nagle(T) could read:
"Delay sending data until there's full MSS, but no longer than period T".
This will guarantee predictable Nagle delay, will not inhibit bulk
transfers,
improve interactive performance and not depend on the receiver's delayed ACK

policy.

Now we have 4 possible solutions: Nagle, modified Nagle, Nagle(N) and
Nagle(T)
it would be interesting to compare their behavior for the cases previously
described, from telnet to bulk transfer to MSS+1 sends.

-----Original Message-----
From: Vernon Schryver [mailto:[email-masked]]
Sent: Friday, February 05, 1999 2:32 PM
To: [email-masked]
Subject: RE: internet draft on suggested mod to the Nagle algorithm

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

> > How would you implement that?  
>
> It's a valid question, however I'd suggest that benefit of the
> algorithm is discussed before perceived implementation complexity.

In general, I strongly disagree.  Implementation costs are never merely
perceived.  Good ideas are a subset of those that have reasonable
implementations.  Without a good implementation, talk aobut the
wonderfulness of any idea is no better than useless usenet jabber, of
which there is no shortage.  Besides, the name of this mailing list
is relevant.  That said, all that's necessary to make it reasonable to
discuss an idea is a plausible hint that it can be reasonably implemented.

> If the recommended value for N is 2, the implementation is trivial,
> consumes extra 2-4 bytes* per TCB and the overhead is 1-2 extra
> instructions per send.
>
> *One can store beginning sequence number of the last packet (4 bytes),
> or the size of the last segment (2 bytes). If storing last segment
> size, then Nagle check would change:
> N=1 (today):	SND.NXT > SND.UNA
> N=2:			SND.NXT -SND.SIZ > SND.UNA 
> where SND.SIZ is last segment size.

"Configurable" implies that sometimes N=1 and other times N=2.  That means
that the time costs are at least the following additional instructions,
  1   fetch of the switch
  2   test of the switch
  3   branch on the switch's value
  4   fetch SND.SIZ
  5   subtract 

Depending on the CPU, you might combine #1, #2, and #3 into 2 instructions,
such as a test and a branch, or a fetch and a branch-zero.  The largest
costs are probably not the instructions but the primary cache misses and
dirtying.  The secondary tertiary cache misses probably don't matter since
the entire TCB is likely to be faulted in and dirtied.  Overall, that
sounds fairly cheap to me.

> Back to the real issue: would allowing N=2 unacknowledged segments 
> resolve effects of Nagle/Delayed ACK interaction?

How is this idea better than the idea of the draft?  

This idea would effectively turn off Nagle for the most common (in my
experience) bad code, which loves write-write-read-write-write-read....
It would double the number of packets on the wire for such bad
applications.  I think that would be Not Good.  Would relaxing Nagle for
2 send requests be much different from turning it off entirely?

Do we agree that I misread the following or it was not tightly phrased?
I read it as a proposal for letting the application vary the value of N
from 1 to some large number.

> > 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.

Vernon Schryver    [email-masked]

---

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

> If W-W-R works well with fwrite, why shouldn't it work with send?

I don't think that if application programmers know what value to set for
your Nagle(N) proposal, they do not know that they are working with a
network device.  If they do not know they are working with a network device,
they'd better not use socket() directly and use some higher level libraries. 
Let those libraries handle the network part.

> improve interactive performance and not depend on the receiver's delayed ACK

What value do you set for T?  First it cannot be larger than 200ms, the
commonly used delay ack timer.  And T has to be dependent on RTT and the
application.  TCP can measure RTT.  But how can TCP know when application
will send?  I'd say TCP will guess wrongly most of the time.  And the most
important question is what we gain for all these complicated work, as
compared to the simple proposed change of Nagle algorithm.

> described, from telnet to bulk transfer to MSS+1 sends.

IMHO, we should not even consider Nagle(T).  And for Nagle(N), I'd say the
little, if any, gain when compared to the proposed change does not justify
the extra code (although smaller than Nagle(T)) implementing it.

							K. Poon.
							[email-masked]