Summary
- RFC 3758 defined a generic FORWARD TSN mechanism, while the upper-layer service defined when a sender should abandon a message.
- Timed reliability did not require an immediate callback at expiry: an implementation could evaluate lifetime at convenient points in a message's processing.
The clock reached zero. The SCTP stack was still allowed to check later.
That is not a contradiction in RFC 3758. It is the line the document drew between a service promise made to an application and the transport mechanism that lets two endpoints recover from a message the sender has chosen to abandon.
The 2004 Standards Track extension did not make all SCTP data unreliable. It let a sending application specify, message by message, how persistent SCTP should be in trying to transmit or retransmit data. When both endpoints negotiated support, the sender could stop pursuing a message and signal that decision with a FORWARD TSN chunk. The receiver would advance its cumulative Transmission Sequence Number (TSN) point and, for ordered data, use stream sequence information to move delivery past a gap.
The mechanism and the decision were deliberately separate. FORWARD TSN carried a new cumulative TSN and, where relevant, the highest skipped ordered sequence number for each stream. It did not tell the receiver which service rule caused abandonment. A deadline, a retransmission ceiling, or another future policy could share the same wire-level recovery signal. RFC 3758 specified one example—timed reliability—and invited other service definitions to specify their own parameters and abandonment rules.
RFC 7496 later added limited-retransmission and priority policies, illustrating that the criterion can change while the forward-progress mechanism remains.
Why not define a special packet for every reason to stop? Because the receiver's job is narrower: process the negotiated extension, mark the indicated TSN space as no longer missing, and make ordered data that was stranded behind the gap eligible for delivery. It need not know whether the sender's application valued freshness, capped retries, or freed send-buffer space. The application-facing policy belongs at the service edge; the receiver-facing consequence belongs on the wire.
That separation has a cost. “Expired” is not identical to “abandoned at that instant.” The timed-reliability rules require the sender to check lifetime before assigning a TSN and again before transmitting or retransmitting a message whose TSN is assigned. But RFC 3758 explicitly lets implementations evaluate lifetime at other convenient opportunities; it says a separate timer per message is unnecessary and does not require an immediate check at the expiry moment. A stack may discover expiration at a later processing event.
The RFC's service definition therefore describes when a message is no longer eligible to be sent once evaluated, not a hard real-time scheduling guarantee for the evaluation itself.
There is also a phase boundary. If a message expires before it receives a TSN, the sender can abandon it without creating a sequence gap to report. If a TSN has already been assigned, the sender marks the data abandoned, applies the specified congestion-accounting rules, and may need FORWARD TSN to let the peer stop waiting. If one fragment of a fragmented message is abandoned, RFC 3758 requires the other fragments of that message to be abandoned too. Sequence space is association-wide while ordered delivery is stream-specific; the chunk carries enough information for both ledgers to advance without pretending the missing payload arrived.
This is not a delivery receipt. A FORWARD TSN says the sender will not continue pursuing certain sequence numbers and asks the peer to advance. It does not prove that an abandoned message reached the receiver, that the next message was accepted by the application, or that a deadline was met end to end. Nor does partial reliability abolish congestion control: abandoned data earns no congestion-window credit, and a retransmission event that would have occurred still has congestion consequences. A freshness policy can stop wasting effort on stale content; it cannot turn transport progress into application success.
The extension also had to be negotiated. Support is signaled in INIT and INIT-ACK. If the peer does not support FORWARD TSN, the association cannot use it; an upper layer that requires partial reliability must learn that fact or choose another course. “My stack has the feature” is not enough. The association-level capability is a separate precondition from the per-message policy and from any later receiver or application outcome.
RFC 3758 thus standardized a useful division of labor rather than one universal meaning for reliability. The wire carries a bounded instruction to skip sequence space; an application-facing service decides when a particular message has ceased to be worth another attempt. Those are related decisions, but they are not the same clock, the same interface, or the same proof.
Sources
- RFC 3758 — SCTP Partial Reliability Extension
- RFC 2960 — Stream Control Transmission Protocol
- RFC 4960 — Stream Control Transmission Protocol
- RFC 9260 — Stream Control Transmission Protocol
- RFC 7496 — Additional PR-SCTP Policies
- RFC 6458 — SCTP Sockets API
- RFC 8260 — Stream Schedulers and User Message Interleaving for SCTP
- RFC 8095 — Services Provided by IETF Transport Protocols and Congestion Control Mechanisms
- RFC 6083 — Datagram Transport Layer Security (DTLS) for SCTP
- RFC 3436 — Transport Layer Security over SCTP
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
