Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!watmath!clyde!cbosgd!ucbvax!usc-isid.arpa!MILLS
From: MILLS@USC-ISID.ARPA
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Zero window probes
Message-ID: <8511111739.AA07725@ucbvax.berkeley.edu>
Date: Mon, 11-Nov-85 12:27:36 EST
Article-I.D.: ucbvax.8511111739.AA07725
Posted: Mon Nov 11 12:27:36 1985
Date-Received: Tue, 12-Nov-85 04:36:48 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 18
Approved: tcp-ip@ucbvax.berkeley.edu

In response to the message sent   Fri, 8 Nov 85 15:57 EST from Mills@CISL-SERVICE-MULTICS.ARPA

John,

See MIL-STD-1778 for another view of the TCP spec, although officially
this and RFC-793 define the same protocol. Speaking pragmatically, the TOPS-20
TCP abandons the connection if the window soes not open in five minutes. The
Fuzzball TCP does the same. You have a similar problem when you send a
FIN, which is ACKed, and the other end never sends a FIN.

If data are queued beyond the right window edge, the user timeout will
catch it. If not, the zero-window probe could continue indefinately, at
least until either new data appears or the connection is closed. This means,
of course that the use would have to proved exactly enough data to fill the
window and then never provide any more.

Dave (no relation)
-------