Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!imagen.UUCP!geof
From: geof@imagen.UUCP.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Re: A New TCP Retransmission Algorithm
Message-ID: <8704171633.AA00225@apolling.imagen.uucp>
Date: Fri, 17-Apr-87 11:33:41 EST
Article-I.D.: apolling.8704171633.AA00225
Posted: Fri Apr 17 11:33:41 1987
Date-Received: Sat, 18-Apr-87 06:07:37 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: imagen!geof@decwrl.DEC.COM
Distribution: world
Organization: The ARPA Internet
Lines: 46

Looks baroque, but ok, until I see:

 >      Note that failing to acknowledge a packet isn't necessarily enough
 >      information since if the remote site closes its window it can still
 >      indicate that it is alive by acknowledging old data.  However, the
 >      geometric backoff means that it might take a very long time to detect
 >      the reopened window.  A window opening ACK wouldn't be acceptable unless
 >      it opened the window farther than it had been before being closed.  Does
 >      anyone admit to actually closing windows?  This might be an argument to
 >      limit the maximum retransmission interval to say, two minutes.  Even
 >      then, you might want a connection to keep trying forever.

YES I CLOSE WINDOWS FOR A LOOOOOOONG TIME -- FROM WHEN THE PRINTER RUNS
OUT OF PAPER UNTIL SOMEONE PUTS MORE PAPER BACK IN.   THREE DAYS IS NOT
UNHEARD OF.  And every TCP implementation that incorrectly times out
just because of a protracted zero window (say 25 seconds) causes a job
to die and us to have an irate customer.  Presumably TCP terminal gw's
do the same thing if you type ^S on the keyboard (or if you attach them
to a printer that is out of paper).

Data that is not acknowledged because there is a zero window IS NOT THE
SAME THING as data that is not acknowledged because it wasn't received.
The sender KNOWS that it is sending into a zero window.  Thus it is
extremely silly for a sender to apply normal retransmission criteria to
a zero window condition.  During zero window, the sender should probe
the connection repeatedly with an interval of 2.5 minutes or so.  These
packets are guaranteed to generate an immediate response (that does
not ack the data), so the response can be used to keep the connection
alive EVEN THOUGH no data is acked.  This is the only place in the TCP
where it is mandated precisely when to send a packet which bears neither
data nor ack (the spec allows them to be sent anywhere, and good practise
mandates that they be sent occasionally, but there is no where else
where they are required).

If 2.5 minutes is too long for you (remember, [1] very few situations
generate a zero window, and [2] the receiver will almost certainly
volunteer a packet that opens the window) then start with a tighter
probe and back it off to 2.5 minutes after a little while.  But don't
use a long backoff as if you were in a congestion situation (when
you've been getting back packets all along) and DON'T RESET THE
CONNECTION.

Please please please fix your buggy implementations to do the right
thing when sending into a zero window.

- Geof