]> Simula Metropolitan Centre for Digital Engineering

Stensberggata 27 0170 Oslo Norway dreibh@simula.no https://www.simula.no/people/dreibh

Internet-Draft This document collects ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned over more than two decades of SCTP deployment.

Introduction

Abbreviations

• SCTP: Stream Control Transmission Protocol

Stream Control Transmission Protocol The Stream Control Transmission Protocol (SCTP) is defined in , , , , , , , , , , , , , . There is also a detailed introduction provided in as well as further informational material at . SCTP is therefore not introduced in more detail here.

Scope The scope of this document is to collect ideas on what to update/change for a next generation of the SCTP protocol. It is a result of lessons learned over more than two decades of SCTP deployment (see also ) as well as ongoing discussions on applying SCTP for WebRTC Data Channels (as introduced in more detail in ).

Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

What to Change in the Next Generation of SCTP?

• Make useful extensions part of the next generation core protocol itself (that is, make their implementation a MUST):
  • Partial Reliability ()
  • Chunk Authentication ()
  • Dynamic Address Reconfiguration ()
  • Stream Reconfiguration ()
  • SACK Immediately ()
• Consider additional features as part of the next generation core protocol:
  • Non-Renegable Selective Acknowledgments (NR-SACK) ()
  • Concurrent Multi-Path Transfer for SCTP (CMT-SCTP) ()
• Chunk Authentication provides integrity but not confidentiality. There could be a feature for encryption as well, such as . Having encryption directly included within the core transport protocol may make it easier to use (less error-prone work for application developers).
• SCTP assigns a fixed TSN per DATA chunk. This TSN can no longer be changed. That is, it is not possible for a middlebox to split chunks into smaller pieces (for example, for hardware offloading). For further discussion: might it be useful to consider a different behavior?
• Definition of path: For SCTP, a path is defined by a remote destination address. , show that CMT-SCTP performance also depends on the local endpoint's outgoing links. Considering each pair of local outgoing and remote incoming addresses as different paths may lead to improved performance in many Internet scenarios.

Security Considerations Security considerations for SCTP can be found in .

IANA Considerations This document introduces no additional considerations for IANA.

Experimental Implementations An Open Source simulation model for SCTP is available for OMNeT++ within the INET Framework. See for the Git repository. For documentation on the model, see and . This model can be used to evaluate future ideas for SCTP.

Testbed Platform A large-scale and realistic Internet testbed platform with support for the multi-homing feature of the underlying SCTP protocol is NorNet. A description of NorNet is provided in and . Further information can be found on the project website .

Acknowledgments The author would like to thank Martin Becke for discussions and support.

Normative References Informative References