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

From: Bernie Volz <[email-masked]>
Date: Wed, 3 Feb 1999 18:56:13 -0400

>Back-up a step here - I thought that the problem being fixed here was
>for request/response applications. From the original rfc txt:
>
>begin quote:
>
>The interaction of delayed ACKs and Nagle
>
>   If a TCP has more application data to transmit than will fit in one
>   packet, but less than two full-sized packets' worth of data, it
>   will transmit the first packet.  As a result of Nagle, it will not
>   transmit the second packet until the first packet has been
>   acknowledged.  On the other hand, the receiving TCP will delay
>   acknowledging the first packet until either i) a second packet
>   arrives (which, in this case, won't arrive), or ii) approximately
>   100ms (and a maximum of 200ms) has elapsed.
>
>   When the sending TCP receives the delayed ACK, it can then transmit
>   its second packet.
>
>   In a request-response protocol, this second packet will complete
>   either a request or a response, which then enables a succeeding
>   response or request.
>
>   Note two (related) bad results of the interaction of delayed ACKs
>   and the Nagle algorithm in this case: the request-response time may
>   be increased by up to 400ms (if both the request and the response
>   are delayed); and, the number of transactions per second is
>   substantially reduced.
>
>end quote.

This is missing one point ... bad applications. In the early days (and I
bet it still happens more often than we would like to think), a lot of
applications sent the request or reply (without the terminator) and then
terminator as two separate writes. Put another way, the message
delimiter and data are not a single write. Even worse, the data may be
"sent" as many small writes. If the amount of data is small, the Nagle
algorithm places lots of delays.

If you look at a trace, you'd see:
				<command> --->
after DELAY_ACK time			  <--- ACK
				<terminator>
after DELAY_ACK time			  <--- ACK or REPLY

Anyway, this is solvable if all applications do "large" writes (write a
single request as one write).

- Bernie Volz
  Process Software

---

From: [email-masked] (Alan Cox)
Date: Thu, 4 Feb 1999 01:33:31 +0000 (GMT)

> single request as one write).

Its actually non trivial because no write is always big enough. You also get
interactions with stuff like sendfile. HP seem to have done a send this
data then the file type thing. Its not clear what the nice answer is. Linux
2.2 has a TCP_CORK option - which is kind of like supernaglei[1]. And also of
course very easy to keep clean in the performance path.

The right answer ? I don't know. I do know that almost every attempt we
made to do self adjusting ack delays didnt work.

[1] Its 'supernagle' as in never send a frame when its not MTU sized

---

From: Rick Jones <[email-masked]>
Date: Wed, 03 Feb 1999 16:54:55 -0800

> data then the file type thing.

When we implemented sendfile(), we made sure that the amalgam (?) of the
header data specified by the application and the file data arrived at
TCP in a way that made it behaves as if it was one "send" call so there
were no Nagle/delayed ACK interactions. 

(Not to say that we didn't experience that in some early protos of
course :)

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