Summary

  • RFC 6525 let selected SCTP streams reset their sequencing state without tearing down the association or changing unlisted streams.
  • Sender’s Last Assigned TSN marked the end of the old epoch. Until the cumulative acknowledgment point reached it, the receiver replied “In progress” and held newer data.
  • Reconfiguration had its own monotonically increasing requests, replay-stable responses and denial result. To forget a data sequence safely, the protocol first had to remember the act of forgetting.

Zero could not make the past leave the network

An SCTP association carries multiple unidirectional streams. In RFC 4960, each DATA fragment received a Transmission Sequence Number across the association, while each ordered user message received a Stream Sequence Number within its stream. RFC 9260 retains that division: TSNs support acknowledgment and duplicate detection; ordered delivery remains local to a stream.

That architecture permits two histories at once. An application may have finished the old purpose of stream 3 while one of its fragments is still being retransmitted. Returning its SSN to zero immediately could make that delayed fragment look as though it belonged to the new purpose. Closing the association would avoid the ambiguity by destroying much more state than necessary, including unrelated streams and path context.

RFC 6525, published in 2012, introduced the RE-CONFIG chunk. It did not remove packets already in flight. It coordinated the point at which both endpoints could close one numbering epoch and begin another.

The last assigned TSN drew a boundary

An Outgoing SSN Reset Request carries a Re-configuration Request Sequence Number, a Response Sequence Number, Sender’s Last Assigned TSN and an optional stream list. No list means all outgoing streams. A list confines the request to those streams and leaves the others unchanged.

Sender’s Last Assigned TSN is the next TSN to be assigned minus one. Before making the request, the sender stops assigning new SSNs to the affected streams and queues later user messages. If it kept sending while the outcome remained unknown, a lost request could leave new sequence numbers on the wire under the old interpretation.

The receiver compares that boundary with its cumulative acknowledgment point. If the point is lower, it enters deferred reset processing. Data for the affected streams with TSNs above the boundary is held locally, and a Re-configuration Response reports “In progress.” That response proves the request was understood. It does not claim the reset is complete.

Only when cumulative acknowledgment reaches the named TSN does the receiver set the next expected SSN to zero for the selected streams, release the held TSNs and return success. Unlisted streams retain their sequence state. A stream becomes new not at a time declared by one application, but at a boundary both endpoints can distinguish.

The command to forget needed its own memory

RE-CONFIG requests use monotonically increasing numbers initialized from the initial TSN. A response copies the request number and can report success, denial, wrong SSN, a request already in progress, a bad sequence number or continuing processing.

If the most recent request arrives again as a retransmission, the receiver returns the same response it returned before. It does not perform a second reset. The operation that changes data numbering is thus protected by an independent control history.

An “In progress” response restarts the requester’s reconfiguration timer without increasing the association error counters. It is not evidence of path failure or congestion. After success, the sender resets the affected outgoing sequencing state, processes queued data and resumes number assignment.

The peer may also deny the request. RFC 6525 calls that an administrative decision and allows it to remain configurable after the association has formed. Support for the extension establishes a language for requesting change; it does not surrender authority over every future change.

Incoming and outgoing were different control surfaces

An SCTP stream is unidirectional. The same stream number in the opposite direction is not automatically one bidirectional conversation; any correlation belongs to the application. An endpoint that wants to reset the sequencing it receives asks its peer to reset the peer’s outgoing stream. The party that assigned the old numbers controls their real cutoff.

SSN/TSN Reset is a separate, broader operation. It resets all incoming and outgoing SSNs and selects new TSN starting points for both directions. The sender stops assigning TSNs while it is pending, and the procedure uses maximum segment lifetime precautions to avoid ambiguity around TSN wraparound. It is not merely a stronger spelling of selected-stream reset.

RFC 6458 exposes SCTP sequences and notification surfaces to applications. RFC 6525 therefore requires explicit application enablement and subscription to reconfiguration notifications. An application that assumes monotonically increasing numbers needs to know when its epoch has changed.

Interleaving changed the counter, not the boundary

RFC 8260 enables user-message interleaving with I-DATA and 32-bit Message Identifiers. When stream sequencing is reset in that mode, two MID counters—one for ordered messages and one for unordered messages—return to zero. Late TSN assignment used by many interleaving schedulers complicates implementation; it does not abolish the old-data boundary.

Stream reset is also not partial reliability. RFC 7496 adds policies for abandoning a message by priority or retransmission count. Abandonment answers how long a sender will pursue one message. Reset answers when a stream’s sequence space may be reused. They alter different state and make different promises.

The IANA SCTP Parameters registry assigns chunk type 130 to RE-CONFIG and records its parameter numbers. It can decode a packet capture. It cannot prove that an implementation supports the extension, two endpoints negotiated it or an application enabled it.

Sources