The TCPv4 specification (RFC 793) classifies a received segment as unacceptable if it has zero length, a sequence number equal to RCV.NXT+RCV.WND while the receive window is not zero (second row in the table).

This essentially means that the segment will be discarded, other than possibly sending an ACK. No ACK processing or send window update will be done.

What is the justification of this?

Consider this scenario:

  1. Host A sends all possible data segments to host B, just exhausting the receive window of B.
  2. Host A shortly also sends an empty segment, e.g. a window update or acknowledgement of received data. This segment has sequence number equal to the right edge of the receive window of host B (RCV.NXT+RCV.WND), since it was set to the latest SND.NXT of host A.
  3. The mentioned data packets are lost in the network or delayed, and host B receives the empty segment first.
  4. Host B will classify the empty segment as not acceptable, and drop it, ignoring any acknowledgement or window update.

This seems to be particularly problematic, because the receiver will typically ignore seemingly older window updates based on the combination of sequence number and acknowledgement number. But just those window updates that won't get filtered out (highest sequence number) would be dropped even earlier due to segments not being considered acceptable.

Is there some part that I am not understanding correctly? Is this scenario really possible?

  • I'm not following you. The second line in the table seems to indicate that if the RCV.WND is greater than 0, then a zero length segment would be accepted. Your condition 1 says that the RCV.WND would be 0. The text under the table says, "If the RCV.WND is zero, no segments will be acceptable, but special allowance should be made to accept valid ACKs, URGs and RSTs."
    – Ron Maupin
    Aug 24 '16 at 0:23
  • @RonMaupin I am concerned about zero-length segments when RCV.WND is nonzero - empty segments with sequence numbers up to but not including RCV.NXT+RCV.WND will be accepted. Why not accept a zero-length segment with sequence number RCV.NXT+RCV.WND? It might be a window update, or acknowledgement of received data. Instead the spec seems to prefer for the receive window to be raised, before accepting another ack or window update from the remote. Aug 24 '16 at 16:41
  • But, in your question, #1 means that RCV.WND is 0. "...just exhausting the receive window of B." If the receive window is exhausted, then you cannot accept any more segments.
    – Ron Maupin
    Aug 24 '16 at 16:49
  • @RonMaupin I did not mean that. By "exhausting the receive window", I mean that A sends on its way all the data that B is ready to accept. As soon as A sends that last segment which ends exactly at RCV.NXT+RCV.WND, any further empty segment will have sequence number equal to RCV.NXT+RCV.WND, and hence may be deemed unacceptable by B. That is, until either B extends the receive window, or all the transmitted data are accepted by B leaving it with a zero window which would then make empty segments from A acceptable again, according to the first row in the table. Aug 24 '16 at 16:57
  • 1
    Yes that's my point, the question is about why this is so. It seems like a "spec bug" to me, since such zero-length segments at the edge of the receive window is expected to be received in case of packet loss or reordering - it can be sent due to ACK of received data or due to a window update. I've looked at Linux kernel and it seems to have a much relaxed check in place allowing this: see github.com/torvalds/linux/blob/… Aug 25 '16 at 6:57

Segment in this context refers to PAYLOAD OF TCP. L=0 toss it. Segment outside of window toss it. S<RCV.NXT+RCV.WND but that is where they mess up in the spec, and it gets fixed in a later RFC.
Any S<RCV.NXT+RCV.WND will be accepted. Like a retransmission. ACKs, SACKS, and window updates are always processed. (The max is used to keep things straight in out-of-order situations)

Hope you graduated!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.