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

From: Art Shelest <[email-masked]>
Date: Fri, 5 Feb 1999 14:06:41 -0800

Vernon Schryver wrote:

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

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.

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

Cheers,

    _Art Shelest.

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

> 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: Greg Minshall <[email-masked]>
Date: Fri, 05 Feb 1999 15:38:35 -0800

Art,

> resolve effects of Nagle/Delayed ACK interaction?

No, it would not.  On at least the BSD stack, the returning ACK won't be sent 
until there are 2*MSS of window update to be sent (or until the delayed ACK 
timer goes off).

Greg