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

From: Kacheong Poon <[email-masked]>
Date: Thu, 11 Feb 1999 18:19:20 -0800 (PST)

While reading all those examples of how the Nagle modification will fail and
how an EPS (explicit push send (-:) will help, I'm wondering if we should also
look at how current delay ack is implemented.  Most stacks delay ack for every
other full MSS segments.  Some delay ack for every other segments regardless
of the size.  And we know how it helps, as explained in section 4.2.3.2
of RFC 1122.

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?

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. 
This does create one more ack as the server should respond immediately after
getting the complete request.  For the HTTP example Henrik sent out, it will
not delay ack for the .25 segment of RES 1.  So the other .25 segment of RES 2
can be sent out after getting the ack.  In this case, it does not create an
extra ack.  Can anyone think of an example when it will still delay ack at the
wrong time?  Or an example when it does not delay ack when it should?

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.

							K. Poon.
							[email-masked]

---

From: Rick Jones <[email-masked]>
Date: Thu, 11 Feb 1999 19:28:27 -0800

> the Nagle modification on a per-send basis?

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.

> is just an exercise on thinking what delay ack strategy should be.

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

rick 
-- 
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, or post, but please do not do both...
my email address is raj in the cup.hp.com domain...

---

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

> unidirectional case, or an assymetric route case.

Yup, this can be a problem.  This is the delayed ack problem described in 
draft-ietf-tcpimpl-cong-control-03.txt, SMSS <> RMSS.  There are some
solutions proposed, though they are not "standardised."  But I guess this
can be worked around.  And there are stacks which already implement solutions
to handle the delayed ack problem.

> Well, it is my belief that "today" an ACK costs just as many CPU cycles

Sometimes the cost can be justified...  I think it is OK in this case to
avoid the extra delay.

							K. Poon.
							[email-masked]