geof@imagen.UUCP.UUCP (04/17/87)
Looks baroque, but ok, until I see: > Note that failing to acknowledge a packet isn't necessarily enough > information since if the remote site closes its window it can still > indicate that it is alive by acknowledging old data. However, the > geometric backoff means that it might take a very long time to detect > the reopened window. A window opening ACK wouldn't be acceptable unless > it opened the window farther than it had been before being closed. Does > anyone admit to actually closing windows? This might be an argument to > limit the maximum retransmission interval to say, two minutes. Even > then, you might want a connection to keep trying forever. YES I CLOSE WINDOWS FOR A LOOOOOOONG TIME -- FROM WHEN THE PRINTER RUNS OUT OF PAPER UNTIL SOMEONE PUTS MORE PAPER BACK IN. THREE DAYS IS NOT UNHEARD OF. And every TCP implementation that incorrectly times out just because of a protracted zero window (say 25 seconds) causes a job to die and us to have an irate customer. Presumably TCP terminal gw's do the same thing if you type ^S on the keyboard (or if you attach them to a printer that is out of paper). Data that is not acknowledged because there is a zero window IS NOT THE SAME THING as data that is not acknowledged because it wasn't received. The sender KNOWS that it is sending into a zero window. Thus it is extremely silly for a sender to apply normal retransmission criteria to a zero window condition. During zero window, the sender should probe the connection repeatedly with an interval of 2.5 minutes or so. These packets are guaranteed to generate an immediate response (that does not ack the data), so the response can be used to keep the connection alive EVEN THOUGH no data is acked. This is the only place in the TCP where it is mandated precisely when to send a packet which bears neither data nor ack (the spec allows them to be sent anywhere, and good practise mandates that they be sent occasionally, but there is no where else where they are required). If 2.5 minutes is too long for you (remember, [1] very few situations generate a zero window, and [2] the receiver will almost certainly volunteer a packet that opens the window) then start with a tighter probe and back it off to 2.5 minutes after a little while. But don't use a long backoff as if you were in a congestion situation (when you've been getting back packets all along) and DON'T RESET THE CONNECTION. Please please please fix your buggy implementations to do the right thing when sending into a zero window. - Geof
sy.Ken@CU20B.COLUMBIA.EDU.UUCP (04/18/87)
Looks baroque, but ok, until I see... Don't know what all the discussion is about. I was always of the mind that 'if it ain't baroque, don't fix it!' (sorry). /K -------
JSLove@MIT-MULTICS.ARPA ("J. Spencer Love") (04/20/87)
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.
-- SpencerKLH@SRI-NIC.ARPA (Ken Harrenstien) (04/20/87)
The ITS TCP implementation, at least, often does reduce the window by more than the amount of bytes acknowledged; what it would really like to use is a packet count, rather than a byte count. It is prepared to recover (by compaction etc) if the sender does not take any notice of the reduced window size, but this was still a conscious decision to live dangerously for the sake of greater efficiency. -------
CLYNN@G.BBN.COM (04/22/87)
Sure, I'll admit to backing up the window, but not to doing it "illegally". The spec says in the "Managing the Window" section that there is an assumption that the window size is related to the currently available data buffer space available for the connection; that is in fact the case - the user/application supplies one or more buffers to be filled with data and the amount of space provided specifies the window. The spec also says in the "Data Communication" section that a Push requires that any data be placed into the user's buffer and the buffer returned to the user even if it is not full. Consequently, the window is reduced by the amount of unused space in the buffer returned to the user in response to a Push. Since there is justification in the spec for reducing the window, and the spec requires senders to deal with it, it is also used in one other case. If a packet is lost, as indicated by reception of several segments in the window but not at the left edge, the window is reduced to the right edge of the missing data to "encourage" the sender to retransmit the missing data and to "discourage" it from sending additional new data or from retransmitting data which was in fact received but couldn't be acked. (If the sender ignores the hint, which we might call a NAK, nothing goes wrong; the receiver will eventually send ICMP Source Quenches which shouldn't be ignored and if that doesn't work packets will be flushed.) This case can be viewed as a situation where the user has provided buffer space but it cannot be used due to the missing segment(s). If a connection is receiving something from the TCP at the other end, even "obsolete acknowledgements", why shouldn't it be kept "alive"? Charlie
JSLove@MIT-MULTICS.ARPA ("J. Spencer Love") (04/22/87)
By "illegally backing up the window," I mean sending an acknowledgement which decreases the offered window but which contains the same sequence number and acknowledgement fields as a previously transmitted acknowledgement. In this case, it appears to the sending TCP as if the acknowledgement arrived out of order. In other words, if two packets arrive with the same sequence and acknowledgement fields, the one which offers the larger window is held to be "more recent." Windows are discussed on pages 42 and 43 of RFC 793. While the behavior described above is not mandatory, it is strongly hinted at. In RFC 813, some discussion of "artificially closing the window" appears in context to refer to keeping the offered window edge fixed rather than backing it up, in order to avoid silly window syndrome. The specification does require that implementations cope with other implementations closing the window in other situations which they may be able to detect. However, it does not require that implementations actually repackage data on the retransmission queue, so this merely means that the implementations are required to cease forming new packets and withhold retransmissions. Since implementations should generally only retransmit the earliest unacknowledged packet, this merely prevents the formation of additional packets, not the delivery of packets already in flight. Thus, your description of the circumstances under which you close the window doesn't necessarily match my description of "illegal" behavior, but it is behavior which the specification describes as "strongly discouraged." In particular, discarding packets which are transmitted into your formerly offered window is a good example of shooting yourself in the foot. Timing out connections which are receiving "obsolete", or if you prefer, "redundant" acknowledgements while being unable to get the most recent packet acknowledged is similar to the zero window probe situation. It is clear that a connection sending into a zero window shouldn't time out as long as redundant ACKs are being received. If a connection sending into a nonzero window should also not time out when only receiving "old" ACKs, then what effect, if any, should this have on the retransmission backoff? In the zero window probe scenario, we don't back off the window probes geometrically, but rather retransmit them infrequently, perhaps every two minutes. This would combine with my previous proposal if the geometric backoff were maxed out at the zero window probe interval, and the receipt of any packet resets the unacknowledged packet counter without affecting the retransmission interval. Then the unacknowledged packet counter becomes the basis for timing out connections. (The unacknowledged packet counter is also not incremented if the retransmission timer is set for an interval of less than one second.)
geof@apolling.UUCP (Geof Cooper) (04/23/87)
> 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 Ooooooohhhhhhh! Sorry. Never Mind. I just like to flame on that particular point. We don't close the window in the way that you mention. - Geof