Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
Extracted elements (28)
PR-SCTP applies the same congestion control to both reliable and partially reliable traffic, ensuring TCP-friendliness unlike UDP. This is identified as a key benefit over using separate protocols for reliable and unreliable content.
The FORWARD TSN delay limits (200ms SHOULD NOT exceed, 500ms MUST NOT exceed) are deliberately matched to RFC 2960's delayed acknowledgement values, because delaying a FORWARD TSN has the same consequences as delaying a SACK but in the reverse direction — the sender's receiver is held up waiting to deliver reordered data.
The receiver-side implementation is agnostic to which PR-SCTP service definition the sender uses; only correct handling of FORWARD TSN chunks is required. This means many varieties of partially reliable services can be implemented without changing the on-the-wire protocol, and without requiring the receiver to understand the sender's service semantics.
The PR-SCTP receiver side can support any PR-SCTP service definition used by the sender, even if the receiver's sending side does not implement that service. The receiver need only correctly handle the Forward-TSN-Supported parameter and FORWARD TSN chunks.
When a receiver of an INIT or INIT-ACK detects a Forward-TSN-Supported parameter but does not support the FORWARD TSN chunk type, it MUST follow the unrecognized parameter rules of RFC 2960 Section 3.3.3, which causes an operational error to be returned.
After processing a SACK, if the Advanced.Peer.Ack.Point is greater than the Cumulative TSN ACK in the SACK, the sender MUST send the receiver a FORWARD TSN chunk containing the latest Advanced.Peer.Ack.Point value.
After receiving a FORWARD TSN, the receiver MUST remove any partially reassembled message still missing one or more TSNs earlier than or equal to the new cumulative TSN point. If partial delivery API is invoked, a notification SHOULD be sent to the upper layer.
Any delay applied to sending a FORWARD TSN chunk SHOULD NOT exceed 200ms and MUST NOT exceed 500ms. These values align with delayed acknowledgement rules in RFC 2960 because delaying FORWARD TSN has symmetric consequences.
Any PR-SCTP service definition MUST specify rule G1: when a message with an assigned TSN is abandoned, the sender MUST mark that TSN as eligible for forward TSN and follow the FORWARD TSN sending rules in Section 3.5 to avoid protocol deadlock.
During processing of a FORWARD TSN, the receiver MUST use stream sequence information to examine all stream reordering queues and immediately make available for delivery any data with stream sequence numbers earlier than or equal to those listed in the FORWARD TSN.
For each abandoned ordered TSN included in a FORWARD TSN, the sender MUST include the stream and sequence number; each stream SHOULD only be reported once using the highest abandoned stream sequence number.
If a FORWARD TSN is sent, the sender MUST assure that at least one T3-rtx timer is running.
If an endpoint chooses NOT to include the Forward-TSN-Supported parameter during association establishment, it MUST act as if it does not support FORWARD TSN and MUST return an ERROR to the peer upon receipt of any FORWARD TSN chunk.
If the decision to abandon a chunk is made and the chunk would have been marked for retransmission (e.g., by T3-Timeout or Fast Retransmit), the appropriate congestion adjustment MUST be made as specified in RFC 2960.
If the New Cumulative TSN in an arriving FORWARD TSN is behind or at the current cumulative TSN point, the receiver MUST treat the chunk as out-of-date and MUST NOT update its Cumulative TSN; it SHOULD send a SACK since the duplicate may indicate the previous SACK was lost.
The out-of-order SACK detection criterion MUST remain based on the Cumulative TSN ACK in the SACK compared to the previous SACK, NOT against Advanced.Peer.Ack.Point.
The Stream Sequence-N field in a FORWARD TSN MUST NOT report TSNs corresponding to unordered DATA chunks; for ordered DATA chunks this field MUST be filled in.
Under the timed reliability service, before assigning a TSN to any message, the SCTP sender MUST evaluate the lifetime of that message; if expired, it MUST NOT assign a TSN and SHOULD issue a notification to the upper layer.
Upon receipt of a FORWARD TSN chunk, the data receiver MUST consider any missing TSNs earlier than or equal to the New Cumulative TSN value as received and stop reporting them as gaps in subsequent SACKs.
When a FORWARD TSN chunk arrives, the receiver MUST first update its cumulative TSN point to the value in the chunk, then MUST further advance its cumulative TSN point locally if subsequent contiguous TSNs are already received.
When a receiver of an INIT that does not contain the Forward-TSN-Supported parameter supports FORWARD TSN itself, it MUST NOT send a FORWARD TSN chunk at any time during the association's life and SHOULD record that the peer does not support it.
When a TSN is abandoned and it is part of a fragmented message, all other TSNs within that fragmented message MUST be abandoned at the same time.
When a TSN is 'abandoned', the sender MUST treat it as finally acked and no longer outstanding, and MUST NOT credit it to partial_bytes_acked or advance cwnd based on it.
The Forward-TSN-Supported parameter (type 49152 / 0xC000) is an OPTIONAL parameter added to INIT and INIT ACK chunks to indicate that the endpoint supports the FORWARD TSN chunk. It has a fixed length of 4 bytes: a 16-bit type field and a 16-bit length field.
IANA assigned chunk type value 192 (0xC0) for the new FORWARD TSN chunk, and parameter type code 49152 (0xC000) for the Forward-TSN-Supported INIT/INIT-ACK parameter.
The FORWARD TSN chunk does not introduce new Man-in-the-Middle attack vectors beyond what is already possible in RFC 2960, since a MIM can already change or withhold data. However, FORWARD TSN does make it easier for a MIM to skip selective messages with less state, when the application has the feature enabled. Applications using PR-SCTP should not use transport layer security; see RFC 3436 for details.
The Advanced.Peer.Ack.Point variable tracks the sender's theoretical view of the peer's cumulative TSN. It advances when: (C1) a SACK arrives with a higher Cumulative TSN ACK; (C2) the next queued chunk is marked 'abandoned'; (A5) any T3-rtx timer expires. It triggers FORWARD TSN generation when it exceeds the SACK's Cumulative TSN ACK.
The FORWARD TSN chunk (type 192 / 0xC0) carries a 32-bit New Cumulative TSN field followed by variable-length Stream-N (16-bit) and Stream Sequence-N (16-bit) pairs, one per skipped ordered stream. Flags are set to 0x00 and ignored on receipt.