Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ucbvax!MIT-MULTICS.ARPA!JSLove
From: JSLove@MIT-MULTICS.ARPA ("J. Spencer Love")
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Re: A New TCP Retransmission Algorithm
Message-ID: <870421230233.317029@MIT-MULTICS.ARPA>
Date: Tue, 21-Apr-87 18:02:00 EST
Article-I.D.: MIT-MULT.870421230233.317029
Posted: Tue Apr 21 18:02:00 1987
Date-Received: Thu, 23-Apr-87 03:09:55 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 49

By "illegally backing up the window," I mean sending an acknowledgement
which decreases the offered window but which contains the same sequence
number and acknowledgement fields as a previously transmitted
acknowledgement.  In this case, it appears to the sending TCP as if the
acknowledgement arrived out of order.  In other words, if two packets
arrive with the same sequence and acknowledgement fields, the one which
offers the larger window is held to be "more recent."

Windows are discussed on pages 42 and 43 of RFC 793.  While the behavior
described above is not mandatory, it is strongly hinted at.  In RFC 813,
some discussion of "artificially closing the window" appears in context
to refer to keeping the offered window edge fixed rather than backing it
up, in order to avoid silly window syndrome.

The specification does require that implementations cope with other
implementations closing the window in other situations which they may be
able to detect.  However, it does not require that implementations
actually repackage data on the retransmission queue, so this merely
means that the implementations are required to cease forming new packets
and withhold retransmissions.  Since implementations should generally
only retransmit the earliest unacknowledged packet, this merely prevents
the formation of additional packets, not the delivery of packets already
in flight.

Thus, your description of the circumstances under which you close the
window doesn't necessarily match my description of "illegal" behavior,
but it is behavior which the specification describes as "strongly
discouraged." In particular, discarding packets which are transmitted
into your formerly offered window is a good example of shooting yourself
in the foot.

Timing out connections which are receiving "obsolete", or if you prefer,
"redundant" acknowledgements while being unable to get the most recent
packet acknowledged is similar to the zero window probe situation.  It
is clear that a connection sending into a zero window shouldn't time out
as long as redundant ACKs are being received.  If a connection sending
into a nonzero window should also not time out when only receiving "old"
ACKs, then what effect, if any, should this have on the retransmission
backoff?  In the zero window probe scenario, we don't back off the
window probes geometrically, but rather retransmit them infrequently,
perhaps every two minutes.

This would combine with my previous proposal if the geometric backoff
were maxed out at the zero window probe interval, and the receipt of any
packet resets the unacknowledged packet counter without affecting the
retransmission interval.  Then the unacknowledged packet counter becomes
the basis for timing out connections.  (The unacknowledged packet
counter is also not incremented if the retransmission timer is set for
an interval of less than one second.)