TCP window probe

Question

I was referred to this site when originally asking in the Networking SE.

I have a few questions about rwnd advertisements in TCP. I have read the RFC but was left with unanswered thoughts (or maybe I have missed some things). Perhaps some of answers are implementation-dependent - in this case please answer using your experience as I wish to know what happens in the general case.

The TCP standard states as follows:

The sending TCP must be prepared to accept from the user and send at least one octet of new data even if the send window is zero.

I assume that the reason for this is that the window probe messages contain one octet of data. However, it made me think:

1. I haven't seen it stated in the standard that probe packets must contain one octet of new data. Are there different ways to probe the window size?

2. If it is the only way, I wonder why resending an old segment (with an old sequence number) will not suffice. Does the receiver have to acknowledge only data that is within the window at a certain moment (meaning old data will not be necessarily acknowledged), meaning that we have to treat probing packets as an exception to that rule?

3. Generally speaking, does the receiver notify the sender when its window grows in size? Does it have to do it (I understand the ack may be lost so the sender may have to probe anyway)?

4. Are probe packets sent only when window = 0 or may they be sent before?

Answer 1

I assume that the reason for this is that the window probe messages contain one octet of data.

Just to be clear, there is no special packet format, or header, or other identifier for a window probe packet. TCP just sends a standard TCP packet when it needs to probe a window. It just happens to limit the user/application data in that TCP packet to one single octet.

1. I haven't seen it stated in the standard that probe packets must contain one octet of new data.

You just quoted the statement in the standard that probe packets must contain at least one octet of new data, didn't you? If you want additional statements, you'll find statements in RFC 793 and RFC 1122 reminding you that Acks with no new application data are not reliably transported (with the implication that you must transmit some new data in order to be able to know if it got through).

Are there different ways to probe the window size?

One could imagine that the authors of the TCP standard could have come up with other ways, but the way you quoted is the only way they provided for in the standard.

2. If it is the only way, I wonder why resending an old segment (with an old sequence number) will not suffice.

It's not a question of if it would suffice, it's a question of what's the best way. If you have no further data to send, you don't need to probe the window. If you do have further data to send, why not use that to probe the window, rather than wasting bandwidth on previously sent (and presumably Ack'd) data?

Does the receiver have to acknowledge only data that is within the window at a certain moment (meaning old data will not be necessarily acknowledged)

The receiver should only acknowledge the latest data it has received, that is contiguous with all the data received since the beginning (by contiguous, I'm saying if it has a hole because it missed one or more packets, but got a later packet, it can't ack that later packet; it has to keep acking the last sequence number before the first hole).

3. Generally speaking, does the receiver notify the sender when its window grows in size?

Yes, generally speaking, the receiver notifies the sender of window size updates with every Ack.

Also, under "Window Management Suggestions" on p. 43 of RFC 793, the authors suggest that TCP receivers "send another acknowledgment with new window information when the window is larger". This RFC predates RFC 2119 that defined the MAY/SHOULD/MUST terminology standards, but this suggestion seems like it would be considered a SHOULD under RFC 2119's requirements levels guidance.

Does it have to do it (I understand the ack may be lost so the sender may have to probe anyway)?

I'm not aware of any RFC updating RFC 793 that would make this behavior into a MUST.

Are probe packets sent only when window = 0 or may they be sent before?

If the window weren't zero, then a single-data-byte TCP segment wouldn't really be considered a probe. For example, if I had a telnet connection that was sending individual keystrokes to the remote host, each keystroke might be sent as a single-data-byte TCP segment. These are fine to send in a case like telnet, even when the window is larger than 0 or 1, but they would not be considered probes.

Answer 2

This builds on Spiff's answer, but with more additions than would fit in a comment. Note that in Aug 2022 RFC9293 finally replaced the original TCP spec and it includes all the MUST/SHOULD/MAY language.

Q1. I haven't seen it stated in the standard that probe packets must contain one octet of new data.

The following requirement, which is not restricted to one octet, was in the original TCP spec RFC793 and was copied verbatim into RFC9293:

When the receiving TCP peer has a zero window and a segment arrives, it must
still send an acknowledgment showing its next expected sequence number
and current window (zero).

Q2. I wonder why resending an old segment ... will not suffice

It's not the most efficient way (if the window becomes large enough, the octet still has to be discarded). But it would work, because TCP congestion control spec's have always said something like RFC5681 now says:

A TCP receiver SHOULD send an immediate duplicate ACK when an out-of-
order segment arrives.

Q3. Generally speaking, does the receiver notify the sender when its window grows in size?

I assume you mean that the receiver's window grows because the receiving application consumes some data from the receive buffer. Then, I believe there is no requirement in the specs to send an ACK to notify this. Hence the need for the window probe, to elicit an ACK.

Q4. Are probe packets sent only when window = 0

Yes, by definition. Because if a one-octet packet were sent before window = 0, it would just be a regular packet that happened to be one octet large.