Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)
Simula Research Laboratory, Network Systems Group
Martin Linges vei 17
1364 Fornebu
Akershus
Norway
+47-6782-8200
+47-6782-8201
dreibh@simula.no
http://www.iem.uni-due.de/~dreibh/
Internet-Draft
This document collects some ideas for a next generation of the
Stream Control Transmission Protocol (SCTP) for further discussion.
It is a result of lessons learned from more than one decade of SCTP
deployment.
SCTP: Stream Control Transmission Protocol
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in
.
The Stream Control Transmission Protocol (SCTP) has been defined as RFCs in
,
,
,
,
,
,
,
,
,
,
,
,
,
.
There is also a detailed introduction provided by as well as lots of further information material on . SCTP is therefore not introduced in more detail here.
The scope of this document is to collect some ideas of what to update/change for a next generation of the SCTP protocol. It is a result of lessons learned from more than one decade of SCTP deployment (see also ) as well as ongoing discussions on applying SCTP for WebRTC Data Channels (as introduced in more detail in ).
Make useful extensions part of the next generation core protocol
itself (that is, make their implementation a MUST):
Partial Reliablility ()
Chunk Authentication ()
Partial Reliablility ()
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, for example like . Having encryption directly included inside 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. The TSN cannot be changed any more. That is, it is not possible for a middlebox to split chunks into smaller pieces (for example, for hardware offloading). For further discussion: may it be useful to consider a different behavior?
Definition of path:
For SCTP, a path is defined by a remote destination address. , shows that CMT-SCTP performance also depends on the local endpoint's outgoing links. Considering each pair of local outgoing and remote incoming address as different path may lead to improved performance in many Internet scenarios.
Security considerations for SCTP can be found in .
This document introduces no additional considerations for IANA.
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.
NorNet is a large-scale and realistic Internet testbed platform with support for multi-homing. A description of and introduction to NorNet is provided in , , , . Further information can be found on the project website at https://www.nntb.no.
The author would like to thank
Martin Becke
for discussions and support.