The use of this implementation detail is already covered verbosely
in RFC-896 (January 1984):
"The solution is to inhibit the sending of new TCP segments when
new outgoing data arrives from the user if any previously
transmitted data on the connection remains unacknowledged. This
inhibition is to be unconditional; no timers, tests for size of
data received, or other conditions are required.
And in RFC-1122:
4.2.3.4 When to Send Data
A TCP MUST include a SWS avoidance algorithm in the sender.
A TCP SHOULD implement the Nagle Algorithm [TCP:9] to
coalesce short segments. However, there MUST be a way for
an application to disable the Nagle algorithm on an
individual connection. In all cases, sending data is also
subject to the limitation imposed by the Slow Start
algorithm (Section 4.2.2.15).
The Nagle algorithm is generally as follows:
If there is unacknowledged data (i.e., SND.NXT >
SND.UNA), then the sending TCP buffers all user
data (regardless of the PSH bit), until the
outstanding data has been acknowledged or until
the TCP can send a full-sized segment (Eff.snd.MSS
bytes; see Section 4.2.2.6).
----
> From: jt@mentat.com (Jerry Toporek)
> > Fri Feb 28 22:00:25 1997 - e0 recv:
> > Ether: len 86 00:00:c0:74:36:20->00:80:c7:5b:e8:a8 type IP
> > IP: len 71 206.31.151.21->206.31.151.78 ihl 20 ttl 254 DF prot TCP
> > TCP: 110->1024 Seq x8c84b492 Ack xcae702c ACK PSH Wnd 17520 Data 31
> ...
> > *** No separate Ack here, but we see a PSH (above) on a short data
> > packet, inexplicably followed by a full data packet (below).
> > That PSH proves that the buffer was idle. AIMS must call OT
> > separately, but no Nagle algorithm!
> >
> > Fri Feb 28 22:00:25 1997 - e0 recv:
> > Ether: len 1514 00:00:c0:74:36:20->00:80:c7:5b:e8:a8 type IP
> > IP: len 1500 206.31.151.21->206.31.151.78 ihl 20 ttl 254 DF prot TCP
> > TCP: 110->1024 Seq x8c84b4b1 Ack xcae702c ACK Wnd 17520 Data 1460
>
> The first segment is short, but the PSH bit indicates that it is all we
> have seen. There is no un-ACKed data, so out it goes. The second segment
> is a full MSS. You seem to have misinterpreted the Nagle algorithm. Please
> go read it again.
>
It's been a long time since I looked at Nagle's RFC-896, but it solved a
pretty serious problem when I worked on my first router implementation
back in '86-87, and I've been beating on vendors to implement Nagle ever
since! I think that I understand it rather well!!!
I apologize that my comment is insufficiently clear. See instead the
next section that appears to be the end of this OT send (labelled #3),
where #1 and #2 remain unacknowledged, yet a short MSS is sent:
*** data packet #3
Fri Feb 28 22:00:25 1997 - e0 recv:
Ether: len 354 00:00:c0:74:36:20->00:80:c7:5b:e8:a8 type IP
IP: len 340 206.31.151.21->206.31.151.78 ihl 20 ttl 254 DF prot TCP
TCP: 110->1024 Seq x8c84ba65 Ack xcae702c ACK PSH Wnd 17520 Data 300
Please remember that you have already admitted (and I already knew) that
you have no API for the application to add a PSH. Therefore, that is
merely the end of a particular OT send.
Anyway, RFC-1122 amends RFC-896: "regardless of the PSH bit".
This is immediately followed by a new OT send of another full MSS that
could have been combined with the previous 300 bytes:
*** data packet #4
Fri Feb 28 22:00:25 1997 - e0 recv:
Ether: len 1514 00:00:c0:74:36:20->00:80:c7:5b:e8:a8 type IP
IP: len 1500 206.31.151.21->206.31.151.78 ihl 20 ttl 254 DF prot TCP
TCP: 110->1024 Seq x8c84bb91 Ack xcae702c ACK Wnd 17520 Data 1460
----
Actually, your argument is disproved in the next trace section:
*** data packet #1
Fri Feb 28 22:00:26 1997 - e0 recv:
Ether: len 86 00:00:c0:74:36:20->00:80:c7:5b:e8:a8 type IP
IP: len 71 206.31.151.21->206.31.151.78 ihl 20 ttl 254 DF prot TCP
TCP: 110->1024 Seq x8c84cf6e Ack xcae703c ACK PSH Wnd 17520 Data 31
*** data packet #2, no Nagle
Fri Feb 28 22:00:26 1997 - e0 recv:
Ether: len 1444 00:00:c0:74:36:20->00:80:c7:5b:e8:a8 type IP
IP: len 1430 206.31.151.21->206.31.151.78 ihl 20 ttl 254 DF prot TCP
TCP: 110->1024 Seq x8c84cf8d Ack xcae703c ACK Wnd 17520 Data 1390
*** data packet #3, short MSS
Fri Feb 28 22:00:26 1997 - e0 recv:
Ether: len 904 00:00:c0:74:36:20->00:80:c7:5b:e8:a8 type IP
IP: len 889 206.31.151.21->206.31.151.78 ihl 20 ttl 254 DF prot TCP
TCP: 110->1024 Seq x8c84d4fb Ack xcae703c ACK PSH Wnd 17520 Data 849
There _is_ outstanding unacknowledged data (#1), and the next segment is
_not_ a full MSS (none of them are). This happens repeatedly throughout
the trace.
I stand by my assertion that you have not correctly implemented Nagle.
----
Finally, just to hit my point home, what is your required API mechanism
to turn off Nagle?
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
This archive was generated by hypermail 2b29 : Tue Sep 19 2000 - 11:44:11 EDT