Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!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: <870420213143.005848@MIT-MULTICS.ARPA>
Date: Mon, 20-Apr-87 16:31:00 EST
Article-I.D.: MIT-MULT.870420213143.005848
Posted: Mon Apr 20 16:31:00 1987
Date-Received: Tue, 21-Apr-87 03:27:47 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 20

No, you don't understand what I meant by "closing a window".  I am
asking, does anyone admit to taking away a window already granted.  That
is, first announcing that a nonzero window is available, and then later
announcing that a smaller window is available than is justified by
additional bytes acknowledged.  This amounts to backing up the edge of
the window, which is explicitly discouraged in the spec.  It is true
that if no additional data can be acknowledged, then the sending TCP
can't tell that the window has shrunk because of the rule for sorting
out old vs new window updates, which only provides for growing the
window if the sequence and acknowledgement fields do not change.

Thus, I am NOT addressing the possibly widespread bug that sending into
a zero window causes timeouts, which it shouldn't, but rather asking if
a connection should be kept alive indefinitely by receiving obsolete
acknowledgements when it *thinks* it has a nonzero window to send into.

This is a variant of the old keepalive controversy, I suppose.  The
question is, does anyone admit to illegally backing up the edge of the
window, not does anyone admit to running out of buffer space.
                                        -- Spencer