SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol
obsoleted by
- rfc-9260 — Stream Control Transmission Protocol
updates
- rfc-4960 — Stream Control Transmission Protocol
Extracted elements (15)
Delayed SACKs reduce performance in sender-detectable situations such as closing an association, hitting window limits, or resetting streams. Because RFC 4960 provides no mechanism for the sender to request immediate acknowledgment in these cases, a new flag bit in the DATA chunk header was chosen as the simplest extension point.
No capability negotiation is required for this extension because RFC 4960 already mandates that unknown chunk flags be ignored by receivers. The sender can gracefully handle a receiver that does not honor the I bit (it simply falls back to delayed SACK behavior), making negotiation unnecessary overhead.
According to RFC 4960, a receiver that does not support this extension will ignore the I bit, since unknown flags in chunk headers are ignored. Because the sender can handle the case where the receiver ignores the bit, there is no requirement to negotiate support for this feature.
RFC 4960 specifies that the Reserved bits in the DATA chunk flags field should be set to 0 by the sender and ignored by the receiver. This pre-existing rule is what allows the I bit extension to be deployed without a handshake or version negotiation.
The sender of a DATA chunk MAY set the I bit whenever it can benefit from the corresponding SACK being returned without delay. The reason the sender has set the I bit is irrelevant to the receiver.
Upon receipt of a DATA chunk with the I bit set, the receiver SHOULD NOT delay the sending of the corresponding SACK chunk; i.e., the receiver SHOULD immediately respond with the corresponding SACK chunk.
Applications using the SCTP_SENDER_DRY_EVENT (from RFC 6458 socket API) can request that the I bit be set on the last DATA chunk of the final user message before waiting for the event, avoiding the delay otherwise introduced by SACK deferral.
If sending a DATA chunk fills the congestion window or receiver window, setting the I bit improves transfer throughput by triggering an immediate SACK that unblocks the sender sooner.
The I (Immediate) bit is defined as bit 0x08 in the flags field of the SCTP DATA chunk header. When set, it signals the receiver that the corresponding SACK chunk should be sent immediately without delay.
The socket API (RFC 6458) is extended by defining the SCTP_SACK_IMMEDIATELY flag, which can be set in snd_flags of struct sctp_sndinfo (for sctp_sendv/sendmsg), sinfo_flags of struct sctp_sndrcvinfo (for sctp_send/sctp_sendx), or the flags parameter of sctp_sendmsg().
When an SCTP association supports Stream Reconfiguration (RFC 6525) and there are pending Outgoing SSN Reset or SSN/TSN Reset requests that require no outstanding DATA chunks, setting the I bit on the last DATA chunk improves reconfiguration performance.
When the association is in the SHUTDOWN-PENDING state, the sender SHOULD set the I bit on outgoing DATA chunks to reduce the number of simultaneously open associations on a busy server handling short-lived associations.
IANA updated the SCTP 'Chunk Flags' registry for the DATA chunk to register the I bit at value 0x08, following the chunk flag registration procedure of RFC 6096. Existing entries (E=0x01, B=0x02, U=0x04) are retained; values 0x10–0x80 remain unassigned.
A malicious sender can set the I bit on every DATA chunk, forcing the peer to emit a SACK for each received packet rather than every other packet. The additional processing cost is limited because, in the absence of loss or reordering, the extra SACKs contain only the simplest form (no gap reports, no duplicate TSNs); furthermore, a receiver sending a SACK per packet is already permitted by RFC 4960, so this does not introduce new traffic volume.
The extended DATA chunk header carries an I bit at flag value 0x08, positioned between the Reserved bits and the U bit. The remainder of the DATA chunk format (Type=0, Length, TSN, Stream Identifier, Stream Sequence Number, Payload Protocol Identifier, User Data) is unchanged from RFC 4960.