[mod.protocols.tcp-ip] TCP retransmission efficiency

karn@MOUTON.BELLCORE.COM (Phil R. Karn) (07/21/86)

A virtual circuit link layer on Ethernet? Surely you jest!  I guess Ethernet
was too simple, cheap, fast and reliable to be left alone by IBM.  Must be
the second law of thermodynamics in action...

I'm not sure John Shriver's scenario with TCP is up to date.  More modern
implementations ("modern" defined as "implementing John Nagle's
recommendations in RFC 896") seldom suffer from this problem.  First of all,
in the majority of situations the Nagle Rule allows only one segment to be
in flight at a time. Obviously a lot of problems go away if you can operate
in "stop and wait" mode.

Only when the bandwidth requirement on the connection exceeds one Maximum
Segment Size per round trip interval will there be more than one segment in
flight at one time.  (This assumes that the receive window is greater than
the MSS, of course.)  Even so, if an early segment gets lost, the receiving
TCP is supposed to place the later segments on its resequencing queue and
quietly await retransmission of the missing segment. When the sender times
out, it is supposed to resend ONLY the oldest unacknowledged segment. This
fills in the hole, and the receiver will now acknowledge all the segments
that it has received. The transfer now continues without any unnecessary
retransmissions.

So as long as the receiver uses "in-window" acceptance (i.e., implements
resequencing) and the sender uses "first-only" retransmission, it's pretty
easy to see that only those segments actually lost are retransmitted.  And
this is done without any incompatible changes to the protocol.

Of course, this assumes that ACKs aren't lost very frequently. If they are,
then it makes sense to consider ACKing ACKs. I.e., ACKs are retransmitted by
the receiver until it gets either a new data packet from the transmitter or
an indication that there is no more data to send. This looks like a good
idea on very lossy networks (e.g., packet radio -- this idea was first
proposed by the Alohanet folks) and I've proposed it for use as an
experimental amateur packet radio link level protocol. At the transport
layer, however, you had better have reasonably low loss rates or the more
costly end-to-end retransmissions (even ACK retransmissions) would eat you
alive.

Phil

karels@MONET.BERKELEY.EDU (Mike Karels) (07/28/86)

Phil:

I'm not sure you're up to date on TCP either.  The Nagle algorithm allows
only one *small* packet in flight (one of less than the maximum
segment size).  Essentially all applications other than telnet/remote
terminal use more than one segment per round-trip interval.  Very few
applications are satisfied with "stop and wait" mode, nor do they refrain
from sending additional data once a maximum segment sized packet has been
sent.

I don't want to think about ACKing ACKs; new data segments are sufficient
acknowledgement, and retransmitted data segments are good enough NAKs.

		Mike

karn@KA9Q.BELLCORE.COM (Phil Karn) (07/28/86)

Forget the Nagle algorithm for the moment; I confused the issue by
bringing it up.

Assuming ACKs aren't lost, unnecessary retransmissions are avoided
as long as you have "first only" retransmission at the sender plus
"in window" acceptance at the receiver.

As I said, "ack retransmission" (i.e., acking acks) is a last-ditch
approach for use over very unreliable links. I'm not sure it'd be
at all appropriate at the transport (host-host) layer.

Phil