Summary

  • SCTP already had a lifetime parameter before partial reliability. The original service could avoid starting an expired message; the extension allowed abandonment after transmission had been attempted.
  • FORWARD TSN communicated a bounded change in what the receiver should wait for. It did not manufacture missing content or establish that the application had received it.
  • The sender could vary its persistence policy while the receiver used a common continuation procedure. Time, retry limits and buffer priority remained narrower than remote validity, successful delivery or recall.

A copy could outlive the decision to keep trying

Consider a hypothetical message already travelling towards its recipient. At the sender, its lifetime runs out and the transport decides not to try again. The earlier copy is still in flight. It reaches the receiver before the notice that says the sender has abandoned it.

This is not a reconstruction of an observed failure. It is a way to expose the difference between limiting future effort and controlling everything that earlier effort has set in motion. A local expiry can stop another attempt. It does not, by itself, make an existing copy disappear or make a receiving application reject it.

The partial-reliability extension for SCTP, published in May 2004 as RFC 3758, addressed a more specific problem than remote cancellation. If the sender stopped trying to fill a numbered gap, how could the receiver continue without waiting forever for that gap to close?

The answer needed two parts. A service policy determined when the sender should give up. A common protocol procedure explained the consequences to the receiver. The policy could vary locally; the meaning of the resulting state change could not.

The first lifetime was a limit on starting

SCTP did not acquire the idea of a message lifetime in 2004. Its original specification, October 2000’s RFC 2960, already allowed an upper layer to supply a lifetime with data submitted for transmission. If the first attempt could not begin within that lifetime, the transport could cancel the work and notify the upper layer.

Once an attempt had begun before expiry, however, the message still had to be transmitted reliably. The parameter could prevent stale work from starting. It did not generally permit a started message to be abandoned while leaving the other side to interpret its absence.

An implementation note suggested delaying assignment of the transmission sequence number, or TSN. For simplicity, assigning that number could itself be treated as the commitment to transmit. The significance was not merely clerical. Once a message occupied positions in a sequence that the transport tracked, ceasing to pursue it could require more than removing an item from a local queue.

September 2007’s RFC 4960 retained the distinction in the base send interface. So did June 2022’s RFC 9260. The optional extension and the base service must therefore be kept separate. It would be wrong either to say that early SCTP had no lifetime or to assume that every later SCTP message could be discarded after a local deadline.

Agreement concerned the procedure, not every reason

Partial reliability was defined per user message. A sending service could decide how persistently to pursue it, while the receiver processed a common indication of abandonment. The receiver did not have to understand the sender’s exact policy to know how to continue.

It did, however, have to support the extension. RFC 3758 signalled that support during association establishment and introduced the FORWARD TSN control chunk. An implementation capable of the extension but choosing not to advertise it had to behave without it for that association. Capability in the software was not the same as negotiated use.

When the peer did not support partial reliability, the upper layer could be told and the initiating endpoint could decline to establish the association or proceed without the extension. A continuing connection was not proof that the intended service had survived unchanged. An application relying on bounded persistence had to account for the difference.

This allocation of responsibility was deliberately narrow. The two sides did not need identical ideas about when an update lost its value. They needed a shared interpretation of the consequences for the sequence after one side decided that an update no longer justified another attempt.

Closing a liability without inventing a receipt

Once a DATA chunk was abandoned, the sender treated it as no longer outstanding, with the internal finality of an acknowledged item. That bookkeeping did not assert that the receiver had obtained the data.

The specification made the separation consequential: abandoned bytes could not contribute the acknowledgement credit used to grow the congestion window. Giving up a transmission was not evidence that the network had carried it. Otherwise, discarding work could have become a way to earn permission to send more.

Abandonment also followed the boundary of the user message. If one fragment was abandoned, every other TSN belonging to that fragmented message had to be abandoned as well. The transport could not keep promising a complete message after deciding not to supply one of its necessary pieces.

The sender maintained an advanced point separately from the receiver’s real cumulative acknowledgement. The variable named Advanced.Peer.Ack.Point represented progress that could be made by accounting for abandoned data. It was not another report of what the peer had actually received.

RFC 3758’s sender example makes the limit concrete. A SACK reports a cumulative acknowledgement of 102. Chunks 103 and 104 have been abandoned. Chunk 105 is neither acknowledged nor abandoned; 106 has been acknowledged. The advanced point can move to 104, but not across 105 to 106. Later success does not discharge an earlier obligation that remains in force.

When the advanced point exceeds the peer’s reported cumulative acknowledgement, the sender transmits FORWARD TSN. For abandoned ordered data, it also supplies stream and sequence information that lets the receiver locate messages stranded behind an abandoned predecessor. Unordered data must not be inserted into those ordered-stream entries.

The freedom to stop trying was thus not a freedom to jump to whichever recent message looked most useful. Unresolved, non-abandoned data still constrained the permissible boundary.

Progress could contain a deliberate absence

The same RFC offers a different example for the receiver. Its cumulative point is 102; 103 is missing, while 104 and 105 are present. Farther ahead, 106 is missing and 107 has arrived. This is not the arrangement in the sender example and should not be read as the next frame of the same trace.

A FORWARD TSN permitting the receiver to pass 103 first advances the point to 103. The already-received 104 and 105 then allow it to move to 105. The missing 106 still prevents further cumulative progress. Nothing has reconstructed the contents of 103.

The new position combines two kinds of evidence: permission to stop waiting for some data, and possession of other data. Reading the final cumulative position as a receipt for every earlier piece would erase that distinction.

Other receive state also needs attention. Ordered messages must be released according to the stream information. An incomplete reassembly still missing a TSN at or below the new boundary has to be removed. If partial delivery to the upper layer has already begun, that layer should be notified that the message will not complete.

The control notice can itself be lost. The sender must keep the necessary retransmission timer running and revisit advancement when it expires. An old or equal FORWARD TSN does not move the receiver backwards; an acknowledgement can help if an earlier acknowledgement was lost. Sending the instruction is not treated as proof that the peer has acted on it.

If skipped DATA arrives after the receiver has advanced beyond it, the described rules treat it as duplicate data and discard it. That governs a late arrival. It does not recover content previously delivered to an application, undo its use or prove that the application never saw it.

No alarm was required for every expiry instant

The timed service in RFC 3758 extends the earlier lifetime beyond the first attempt. Before assigning a TSN, the sender must check whether the message has expired. If it has, the sender does not assign the number, abandons the message and should notify the upper layer. Avoiding the numbered obligation can avoid the need for FORWARD TSN.

For data already assigned a TSN, lifetime is checked before transmission or retransmission. An expired message enters the abandonment procedure. The application must not change its lifetime after handing it to SCTP.

Yet the design does not require a separate timer for each message. It permits checks at points where work is already being done, including number assignment, transmission and retransmission-timer expiry. An implementation may check at other convenient moments without being required to evaluate every message at its precise expiry instant.

The resulting inference is limited but important. The lifetime governs sender activity; it does not itself establish a synchronized validity deadline at the receiver. The hypothetical in-flight copy at the start of this article illustrates the boundary. Stopping future attempts does not prove that a previous attempt will be rejected.

An application that must refuse stale state needs its own acceptance rule, whether based on a version, a suitable time condition or other evidence. A transport persistence limit cannot supply that property simply because its parameter is called a lifetime.

More reasons to stop, the same way to proceed

December 2011’s informational RFC 6458 described a sockets interface with a policy selector and associated value. Reliable service was distinguished from timed reliability, whose value was expressed in milliseconds. This interface description did not establish identical numeric constants or defaults across all implementations.

In April 2015, RFC 7496 added policies including a limit on retransmissions. The count applies to each DATA chunk belonging to the message. If retransmitting any chunk would exceed its permitted count, the whole message is abandoned. Both fast and timer-driven retransmissions count.

A zero limit therefore permits the initial send and abandons the message when the first retransmission would otherwise occur. It means neither “never send” nor “one successful delivery”. Required congestion and retransmission-timeout processing still applies, and the policy does not replace path or association failure thresholds.

A priority policy addresses a different scarcity: space in the send buffer. To admit a new message, the sender can abandon lower-priority messages in the same association. Reliable messages rank above those subject to this priority policy. The ranking allocates local buffer space; it does not command preferential forwarding by the network or preferential execution by the peer.

January 2021’s RFC 8831 required timed and limited-retransmission partial reliability for WebRTC data channels. Ordered delivery and reliability remained separate choices. In that stack SCTP runs over DTLS, then ICE/UDP. A historical restriction involving TLS over SCTP must not be expanded into a claim that partial reliability precludes encryption.

These documents establish specifications and interface choices, not a current census of browser behaviour. Their historical continuity is narrower: new local reasons to abandon work could reuse a common receiver procedure, instead of teaching the receiver every new policy.

FORWARD TSN did not make missing data arrive. It made it possible to continue while explicitly accepting that certain data would not be pursued. The sender gained discretion over effort, not the power to turn that discretion into a delivery receipt.

Sources

  • RFC 2960: the original lifetime and first-transmission distinction.
  • RFC 3758: support negotiation, abandonment, FORWARD TSN and timed reliability.
  • RFC 4960: the subsequent base send interface.
  • RFC 6458: informational sockets policy selection.
  • RFC 7496: retransmission limits, buffer priority and abandonment statistics.
  • RFC 8831: WebRTC data-channel requirements and layering.
  • RFC 9260: the 2022 base SCTP interface.