3.1.5.2.1 Send Sequence ID (bSeq) Validation and Processing

  • Article

The maximum number of unacknowledged, outstanding packets that an implementation can have at a single time is 64, and therefore, the bSeq field MUST either be the next sequence ID that is expected by the receiver, or a later ID that is less than or equal to the expected ID plus 63. If the sequence ID is outside this range, a selective acknowledgment (SACK) packet SHOULD be sent that indicates the current expected state. If the PACKET_COMMAND_POLL flag is set in bCommand, this packet SHOULD be sent immediately. Otherwise, the dedicated acknowledgment (ACK) timer SHOULD be set by using the short time-out (nominally 20 milliseconds), and the SACK packet SHOULD be sent at that time. The payload of the received packet MUST then be ignored.

After all other validation is performed and the packet has not been ignored, this bSeq value MUST become the new expected sequence ID. If the logic in the previous paragraph is used, receiving a retried packet that has the same bSeq value is treated as a duplicate.

Sequence IDs start at 0 for every connection. Therefore, each partner's next send value from which bSeq is generated MUST start at 0 for every connection.

If the sequence ID is the next expected, the receiver SHOULD process the payload and advance the expected sequence ID. If the sequence ID is out of order, but still within 63 packets, the receiver SHOULD queue the payload until it receives either:

  • A delayed or retried transmission of the missing packet or packets, and can now process the sequence in order.

  • A subsequent packet with a send mask indicating that the missing packet or packets did not use PACKET_COMMAND_RELIABLE and will never be retried. Therefore, the receiver advances its sequence as if it had already received and processed the packets.

If an implementation has out-of-order packets beyond the current expected sequence ID queued, it SHOULD indicate this to the sender using appropriate SACK masks on any outgoing SACK–based messages. This feedback enables the sender to avoid retrying packets that have already been successfully received.