Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!nbires!hao!hplabs!ucbvax!MOUTON.BELLCORE.COM!karn
From: karn@MOUTON.BELLCORE.COM (Phil R. Karn)
Newsgroups: mod.protocols.tcp-ip
Subject: TCP retransmission efficiency
Message-ID: <8607211927.AA05073@mouton.bellcore.com>
Date: Mon, 21-Jul-86 15:27:53 EDT
Article-I.D.: mouton.8607211927.AA05073
Posted: Mon Jul 21 15:27:53 1986
Date-Received: Tue, 22-Jul-86 07:23:50 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 39
Approved: tcp-ip@sri-nic.arpa

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