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!burl!ulysses!ucbvax!tcp-ip
From: tcp-ip@ucbvax.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Zero window probes
Message-ID: <8511220342.AA18645@decwrl.DEC.COM>
Date: Thu, 21-Nov-85 15:57:42 EST
Article-I.D.: decwrl.8511220342.AA18645
Posted: Thu Nov 21 15:57:42 1985
Date-Received: Mon, 25-Nov-85 07:38:12 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 20
Approved: tcp-ip@sri-nic.arpa

(Sorry for the delay in sending this, we've been off the net for a week)
Charles Hedrick's printer is probably one of ours, and I agree with him
heartily.  I believe that you have to take flow control at face value:
it allows the RECEIVER to receive data as slow as IT wants.  The sender
should always allow the receiver to arbitrarily delay the connection, as
long as the sender has evidence that the connection is still valid --
acks coming back across the connection.  Higher level protocols may
proclaim higher-level timeouts if they cannot accept this behavior.

If you don't take this policy, then you require arbitrary buffering in
slow hosts.  I know this to be true, because I'm responsible for the
TCP on about the slowest host out there -- an Imagen laser printer.  The
printer has no place to buffer files as they are received, it processes
and prints them as it receives them across the TCP connection.  There is
no zero window timeout which is "reasonable."  If the printer runs out of
paper or jams in the middle of the night, it might hold the connection in
zero window until morning.

- Geof Cooper
  Imagen