3

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?

7
  • 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, 2016 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, 2016 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, 2016 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, 2016 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, 2016 at 6:57

3 Answers 3

1

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!

0

Okay, so here's that table:

    Segment Receive  Test
    Length  Window
    ------- -------  -------------------------------------------

       0       0     SEG.SEQ = RCV.NXT

       0      >0     RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND

      >0       0     not acceptable

      >0      >0     RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
                  or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

According to your scenario, for the packet of interest, SEG.SEQ = RCV.NXT+RCV.WND, SEG.LEN = 0, and RCV.WND > 0.

So yes, we need to look at the second row, and indeed, that test doesn't pass, which doesn't make a lot of sense.

Maybe report an erratum?

0

I do not see a situation where host A sends an empty segment in your scenario.

A is supposed to send packets up to the receiver window and then wait for ACKs [your item 1]. If nothing is received in response there are retransmissions, and retransmissions have sequence number < RCV.NXT+RCV.WND. A will not send an empty packet with sequence number outside of receiver window if it did not receive anything from B. So, your item 2 cannot happen.

If anything is received by A, that means that A has received an ACK (which updates SND.UNA) and with it new value of receiver window, so A either knows new receiver window or that receiver window is empty. This means next sequence number will be inside receiver window. Thus it will not result in missing check in line 2. Thus again, item 2 will not happen.

If A knows that receiver window is empty, it will indeed send a zero-length packet called zero-window probe. But this is conditioned on A receiving a zero-length receiver window from B, so again your situation cannot happen. Also, window probes are ACKed, so again both A and B know that the receiver window is zero, and A can select a sequence number SEG.SEQ = RCV.NXT.

So, to summarize, it is actually a sender error, if the sender sends a segment with a sequence number outside of receiver window.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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