Haas@UTAH-20.ARPA (Walt) (01/17/86)
One of our TCP implementations (TOPS-20) opens a TCP connection with a segment that contains the usual SYN and a window size of zero. According to one interpretation of the spec there should be no legal response to such a segment since the normal response is SYN+ACK and the SYN in the response would take up sequence number space, which does not exist according to the sender of the first segment. According to another intepretation, the window size refers to data octets only, and the sequence number space taken by SYNs and FINs shouldn't count. Various implementations handle this in various ways - some apparantly assume that it's silly to send SYN with a window size of zero, and just go ahead and reply with SYN+ACK. One implementation appears to go into a tight loop in this situation. Does anybody have any references that would resolve the apparent ambiguity? It isn't clear to me how to apply the robustness principle to this case - one could imagine that an implementation could have an unusual situation where it needed to open a connection but didn't at the moment have any place to put a reply. Thanks in advance for any helpful comments -- Walt -------
CERF@USC-ISI.ARPA (01/17/86)
Walt, since one could not successfully "open" a connection without getting the matching SYN-ACK, it seems appropriate for the recipient of such a packet to respond, despite the apparent violation. As you know, it is allowed to send at least one octet into a closed (0) window to assure that when it opens you hear that. The SYN can safely elicit an ACK without opening the window any further. Depending on the implementation, some systems don't apply the window size until AFTER the connection has reached the OPEN state which it cannot get to without first exchanging SYN-ACKs. Jon Postel will undoubtedly have a reference to page xx para gg and sugestion to look in one of Dave Clark's marvelous tutorial sections... Vint Cerf
Lepreau@UTAH-20.ARPA (Jay Lepreau) (01/18/86)
This recently came up in another context: the TAC's put garbage in the window field in their initial SYN, all the way up to 64K. This raised havoc with some of our hosts which remembered the max window size they'd ever seen. I talked to the TAC folks at BBN who maintained that since the window is only defined relative to the ack seq number, the window is meaningless unless ACK is set, and therefore it's not their bug, it's ours. Sounds plausible, so we fixed it here. (A zero initial window is quite good behavior, in contrast with the TAC's, which are clearly violating the robustness principle.) -------