[mod.protocols.tcp-ip] Regarding extended ACKs under congested conditions

jbn@GLACIER.STANFORD.EDU.UUCP (12/16/86)

       A proper TCP should, under heavily congested conditions reported
to it via ICMP Source Quench messages, throttle back to one packet outstanding
at a time, and become a stop-and-wait protocol.  At that point, the need for
extended ACks vanishes.  However, if one is operating over an uncongested
but error-prone link, such as a packet radio link without link-level error
control, something like extended ACKs would not be a bad idea.  

       Clearly fragmenting in the presence of errors introduces terrible
problems.  Some of these problems are alleviated if the IP sequence number
is retained over retransmissions, so that fragments generated from multiple
retransmissions of the same TCP segment can be reassembled.  I still argue,
though, that nothing should send a packet bigger than 576 bytes without
some external reason to know that it won't be fragmented.  The IP standard,
of course, says that all nets must handle 576 byte datagrams.  There's still
some antiquated hardware around that can't, but it's a miniscule percentage
of the net today.

       But none of these matters address the real issue that is killing the
net, which is, of course, the combination of badly-behaved hosts and gateways
that can't defend themselves against overload.  But we've been through this
before, and I've written enough on that subject previously.  Still, it's 
embarassing that it hasn't been fixed yet.

				John Nagle