Summary

  • SCTP's peel-off operation moves an established association from a one-to-many socket to its own one-to-one socket. Subsequent data and control operations use the new descriptor.
  • Closing the original socket does not terminate the extracted association. Any isolation decision must therefore include a separate lifecycle and cleanup decision.

The last close in a shutdown routine can leave more work alive than its author intended. With SCTP, the reason need not be a lost signal or a remote peer refusing to cooperate. The application may earlier have changed which socket controls the association. The close can do exactly what its interface promises and still fail to reach the association that an operator thought remained inside its remit.

The relevant operation is sctp_peeloff. In the sockets API described by RFC 6458, it branches an established association away from a one-to-many socket into a separate, one-to-one socket. It does not negotiate a replacement association. The communication relationship already exists; the local interface used to operate it changes.

That distinction makes peel-off an unusually concrete example of a management problem: a resource can be separated for good reasons while its termination responsibility remains attached, in someone's mental model, to the old container. The result is not necessarily a protocol failure. It is a mismatch between the application's control inventory and its actual socket structure.

Why the shared socket becomes uncomfortable

A one-to-many socket lets an application handle several SCTP associations through one descriptor, identifying the particular association when needed. That economy is useful, but it does not make all the resources behind the interface independent.

Section 3.3 of RFC 6458 considers an implementation that shares an outbound buffer allocation across associations. If one association stops making progress, its queued data can consume the allocation and prevent sends on other associations. Merely making the socket nonblocking does not remove this coupling. A call can avoid waiting while still encountering an exhausted common resource.

The document describes several responses. An implementation can reserve buffer space per association. An application protocol can bound the amount of unread data. An application can use one-to-one sockets from the outset, or peel off an association before a large exchange that might stall. These are different places to put the constraint: inside resource allocation, inside application behavior, or at the socket boundary.

None is a portable performance forecast. The buffer discussion is conditional on implementation choices. It does not establish how much memory a particular operating system will allocate, how existing queued bytes will move, or whether a specific workload will become faster. The defensible claim is narrower: the API offers a way to stop treating selected established work as part of the same socket-level operating surface.

A branch is not an arrival

The caller supplies both the original socket and the identifier of the association to extract. On success, the return value is a nonnegative descriptor for the new socket; failure returns minus one with an error indication. Unlike an ordinary acceptance of an arriving connection, the application has selected an association it already has.

Section 9.2 makes the next step explicit: all subsequent control and data operations on that association use the new socket. The original descriptor is no longer the right address for those operations. Crucially, closing the original socket does not terminate the branched association.

Imagine a service that groups many associations under a common intake socket and extracts a particularly demanding exchange. This is an illustrative design, not a report of a deployed system. A later instruction to close the intake socket reaches the associations still represented there. It does not reach the extracted exchange merely because that exchange once entered through the same socket. The service needs to retain the new descriptor in the set of work it intends to manage.

The benefit and the obligation arise from the same act. The application has acquired a more separate control surface, not simply performed an invisible optimization. Describing the operation as “moving traffic” understates it: control operations move too.

Policies have a socket type

Options add a second boundary. RFC 6458 explains that socket- and IP-level options have socket scope. On a one-to-many socket, that means the associations belonging to that socket; on a one-to-one socket, it means the association represented there. Its buffer sections also distinguish implementation-dependent one-to-many behavior from the simpler one-to-one case.

Idle cleanup illustrates why a policy inventory matters. Section 8.1.8 documents SCTP_AUTOCLOSE only for one-to-many sockets. The option concerns inactivity in user data, is disabled by its default zero value, and otherwise uses a time in seconds. Applications seeking notification of these closures need association-change events enabled.

This does not establish what happens to an already armed timer during peel-off. The selected API text is not a basis for asserting automatic cancellation, reset or inheritance. The practical implication is to verify the intended lifetime policy for the new socket and the actual implementation, rather than assume that a setting associated with the old socket type remains sufficient.

Termination is not one undifferentiated operation either. Closing a one-to-one socket normally initiates graceful SCTP shutdown and makes the descriptor unavailable for subsequent operations. With SO_LINGER enabled and a zero linger time, close instead aborts the association. A positive linger time bounds how long close waits; the protocol shutdown can continue after the call returns. An application that needs notifications during termination can consider the described shutdown interface, remembering that SHUT_WR invokes full SCTP protocol shutdown, not TCP-style half-close.

These details change what a cleanup record should mean. “Close requested,” “descriptor released” and “protocol shutdown completed” need not be interchangeable events. Nor does any of them, by itself, settle an application's business transaction.

What the evidence supports

The RFC Editor record identifies this as an Informational document published in December 2011. It is an API account, not a current inventory of operating-system implementations. The retrieved errata include verified corrections elsewhere in the document; held and rejected entries must not be treated as equivalent accepted changes. No direct correction to section 9.2 appeared in that list.

The governance connection is an interpretation, not another protocol requirement. In his essay on the agency problem, Lu Heng asks how decision rights relate to exposure to consequences. Here that question becomes specific: does the person accepting the isolation benefit also know who will terminate the separated work? His account of BTW Media's purpose favors observable reality over advocacy. Applied here, that means following the new descriptor, rather than treating a tidy shutdown narrative as evidence that every association ended.

Peel-off is not inherently dangerous. It makes a useful boundary explicit. The danger lies in documenting the performance choice while leaving the new closure responsibility undocumented.