Mills@CISL-SERVICE-MULTICS.ARPA (11/08/85)
I am wondering what the appropriate action for a TCP connection that is sending out zero window probes and recieveing ACKS for the last octet of the window. For a small amount of time you obviously want to keep the connection around in case the window opens. The real question comes in when the window has been closed for some time. One argument is, that if you are recieving valid ACKS the other end is alive so keep the connection open. The other is that if has been that long since you were able to transmit something is probably wrong with the connection. In looking in RFC-793 this issue seems to be rather glossed over. I am using the September '81 version of the RFC form the protocol transition workbook. Is this the up-to-date spec? Any information or pointers into the specs would be very helpful. Thanks, John Mills
MILLS@USC-ISID.ARPA (11/11/85)
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) -------
HEDRICK@RED.RUTGERS.EDU (Charles Hedrick) (11/12/85)
If this is what I think it is, I think it depends upon the application. If you are a TCP user process, and the other end doesn't accept any data in 5 minutes, there is probably something wrong. But suppose you are a print spooler talking to a remote printer. We have a situation just like that. When the printer runs out of paper, or is otherwise in need of attention, it XOFF's the connection. Eventually, the result is that TCP refuses to accept any data. The operator may take a long time to get to this. We'd like to keep the connection open as long as necessary. Similarly, consider the connection between a host and one of our terminal servers. The terminal server allows a user to have several connections open at once. However the terminal is connected to only one session at a time. There are commands to let you go back and forth between connections. Obviously the server has only a finite buffer. When you are not connected to a session, and its buffer fills, TCP will stop accepting data. Again, we would like the host to keep the connection open indefinitely. Currently TOPS-20 will time out after a certain time. Our users all consider this to be a bug. They are annoyed when they reconnect to a TOPS-20 session and find that TOPS-20 has given up. -------
CERF@USC-ISI.ARPA (11/12/85)
John, The philosophical basis for the TCP design, if not stated explicitly, was that the TCP protocol and implmentation could not and should not make too many timeout decisions on behalf of a using process. Only the using process (or perhaps a person) knows how long it is willing to "wait" for some action. Consequently we assigned no value for timing out the condition you describe and instead assumed that the using process would eventually close the connection unilaterally when it wanted to. of course, if you get no ACK back from the probe, you timeout and report this to the using process but you still do not unilaterally close the connection at the TCP level. Vint
cak@PURDUE.EDU ("Christopher A. Kent") (11/12/85)
4.2 has the silliness of closing down a connection after a (short) finite amount of time of pushing against a zero window. The behaviour is much as described for Rutgers' terminal server; rlogin somewhere, cat /etc/termcap, suspend, work a while, come back and find the connection dead. Get pissed off. Sigh, chris ----------
tcp-ip@ucbvax.UUCP (11/21/85)
(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
DCP@SCRC-QUABBIN.ARPA (David C. Plummer) (12/09/85)
(Sorry for the slow comment, I've been off the net for a month.) I agree with the philosophical basis as stated by CERF. TCP allows the sending of one byte beyond the window for the purposes of probing. Since the byte is outside the window, the receiver MUST send an ACK. This shows that both TCP's are alive, and it is up to the higher level protocols to decide that the connection is worthless, even though the connection still validly exists. Therefore, I believe TOPS-20 and Unix (whichever version somebody mentioned) are in error by having TCP do the timeout.