draft-ietf-tsvwg-sctp-ndata.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc strict="yes" ?>

<rfc category="std"
     ipr="trust200902"
     docName="draft-ietf-tsvwg-sctp-ndata-13.txt">
<front>
<title abbrev="Stream Schedulers and the I-DATA Chunk">
       Stream Schedulers and User Message Interleaving
       for the Stream Control Transmission Protocol
</title>

<!-- *************** RANDALL STEWART *************** -->
<author initials="R. R." surname="Stewart" fullname="Randall R. Stewart">
<organization>Netflix, Inc.</organization>
<address>
    <postal>
        <street></street>
        <city>Chapin</city> <region>SC</region>
        <code>29036</code>
        <country>United States</country>
    </postal>
    <email>randall@lakerest.net</email>
</address>
</author>

<!-- ************** MICHAEL TUEXEN *************** -->
<author initials="M." surname="Tuexen" fullname="Michael Tuexen">
<organization abbrev="Muenster Univ. of Appl. Sciences">
              Muenster University of Applied Sciences</organization>
<address>
    <postal>
        <street>Stegerwaldstrasse 39</street>
        <city>48565 Steinfurt</city>
        <country>Germany</country>
    </postal>
    <email>tuexen@fh-muenster.de</email>
</address>
</author>

<!-- *************** SALVATORE LORETO ************** -->
<author initials='S.' surname='Loreto' fullname='Salvatore Loreto'>
  <organization>Ericsson</organization>
  <address>
    <postal>
      <street>Torshamnsgatan 21</street>
      <city>164 80 Stockholm</city>
      <country>Sweden</country>
    </postal>
    <email>Salvatore.Loreto@ericsson.com</email>
  </address>
</author>

<!-- ************** ROBIN SEGGELMANN *************** -->
<author initials="R." surname="Seggelmann" fullname="Robin Seggelmann">
<organization>Metafinanz Informationssysteme GmbH</organization>
<address>
    <postal>
        <street>Leopoldstrasse 146</street>
        <city>80804 Muenchen</city>
        <country>Germany</country>
    </postal>
    <email>rfc@robin-seggelmann.com</email>
</address>
</author>
<date />

<keyword>Internet-Draft</keyword>

<abstract>
<t>The Stream Control Transmission Protocol (SCTP) is a message oriented
transport protocol supporting arbitrarily large user messages.
This document adds a new chunk to SCTP for carrying payload data.
This allows a sender to interleave different user messages that
would otherwise result in head of line blocking at the sender.
The interleaving of user messages is required for WebRTC Datachannels.</t>

<t>Whenever an SCTP sender is allowed to send user data, it may choose from
multiple outgoing SCTP streams.
Multiple ways for performing this selection, called stream schedulers, are
defined in this document.
A stream scheduler can choose to either implement, or not implement,
user message interleaving.</t>
</abstract>

</front>

<middle>
<section title="Introduction">
<section title="Overview">
<t>When SCTP <xref target='RFC4960'/> was initially designed it was mainly
envisioned for the transport of small signaling messages.
Late in the design stage it was decided to add support for fragmentation and
reassembly of larger messages with the thought that someday Session Initiation
Protocol (SIP) <xref target='RFC3261'/> style signaling messages may also need
to use SCTP and a single Maximum Transmission Unit (MTU) sized message would
be too small.
Unfortunately this design decision, though valid at the time, did not account
for other applications that might send large messages over SCTP.
The sending of such large messages over SCTP as specified in
<xref target='RFC4960'/> can result in a form of sender side head of line
blocking (e.g., when the transmission of a message is blocked from
transmission because the sender has started the transmission of another,
possibly large, message).
This head of line blocking is caused by the use of the Transmission Sequence
Number (TSN) for three different purposes:
<list style="numbers">
<t>As an identifier for DATA chunks to provide a reliable transfer.</t>
<t>As an identifier for the sequence of fragments to allow reassembly.</t>
<t>As a sequence number allowing up to 2**16 - 1 Stream Sequence
Numbers (SSNs) outstanding.</t>
</list>
The protocol requires all fragments of a user message to have consecutive
TSNs.
This document allows an SCTP sender to interleave different user messages.</t>
<t>This document also defines several stream schedulers for general SCTP
associations allowing different relative stream treatments.
The stream schedulers may behave differently depending on whether user
message interleaving has been negotiated for the association or not.</t>
<t><xref target='RRwithoutMI'/> illustrates the behaviour of a round robin
stream scheduler using DATA chunks when three streams with the Stream
Identifiers (SIDs) 0, 1, and 2 are used. Each queue for SID 0 and SID 2 contains
a single user message requiring three chunks, the queue for SID 1 contains
three user messages each requiring a single chunk. It is shown how these
user messages are encapsulated in chunk using TSN 0 to TSN 8.
Please note that the use of such a scheduler implies late TSN assignment but
it can be used with an <xref target='RFC4960'/> compliant implementation that
does not support user message interleaving.
Late TSN assignment means that the sender generates chunks from user messages
and assigns the TSN as late as possible in the process of sending the user
messages.</t>
<figure title='Round Robin Scheduler without User Message Interleaving'
        anchor='RRwithoutMI'>
<artwork>
+---+---+---+
|    0/0    |-+
+---+---+---+ |
              |  +---+---+---+---+---+---+---+---+---+
+---+---+---+ +->|1/2|1/1|2/0|2/0|2/0|1/0|0/0|0/0|0/0|
|1/2|1/1|1/0|--->|---|---|---|---|---|---|---|---|---|
+---+---+---+ +->| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
              |  +---+---+---+---+---+---+---+---+---+
+---+---+---+ |
|    2/0    |-+
+---+---+---+
                               +-------+
  +-------+                    |SID/SSN|
  |SID/SSN|                    |-------|
  +-------+                    |  TSN  |
                               +-------+
</artwork>
</figure>
<t>This document describes a new chunk carrying payload data called I-DATA.
This chunk incorporates the properties of the current SCTP DATA chunk,
all the flags and fields except the Stream Sequence Number (SSN),
but also adds two new fields in its chunk header, the Fragment Sequence
Number (FSN) and the Message Identifier (MID).
The FSN is only used for reassembling all fragments having the same MID
and ordering property. The TSN is only used for the reliable transfer in
combination with Selective Acknowledgment (SACK) chunks.</t>
<t>In addition, the MID is also used for ensuring ordered delivery instead
of using the stream sequence number (The I-DATA chunk omits a SSN.).</t>
<t><xref target='RRwithMI'/> illustrates the behaviour of an interleaving
round robin stream scheduler using I-DATA chunks.</t>
<figure title='Round Robin Scheduler with User Message Interleaving'
        anchor='RRwithMI'>
<artwork>
+---+---+---+
|    0/0    |-+
+---+---+---+ |
              |  +-----+-----+-----+-----+-----+-----+-----+-----+-----+
+---+---+---+ +->|2/0/2|1/2/0|0/0/2|2/0/1|1/1/0|0/0/1|2/0/0|1/0/0|0/0/0|
|1/2|1/1|1/0|--->|-----|-----|-----|-----|-----|-----|-----|-----|-----|
+---+---+---+ +->|  8  |  7  |  6  |  5  |  4  |  3  |  2  |  1  |  0  |
              |  +-----+-----+-----+-----+-----+-----+-----+-----+-----+
+---+---+---+ |
|    2/0    |-+
+---+---+---+
                                     +-----------+
  +-------+                          |SID/MID/FSN|
  |SID/MID|                          |-----------|
  +-------+                          |    TSN    |
                                     +-----------+
</artwork>
</figure>
<t>The support of the I-DATA chunk is negotiated during the association setup
using the Supported Extensions Parameter as defined in
<xref target='RFC5061'/>.
If I-DATA support has been negotiated for an association, I-DATA chunks are
used for all user-messages.
DATA chunks are not permitted when I-DATA support has been negotiated.
It should be noted that an SCTP implementation supporting I-DATA chunks needs
to allow the coexistence of associations using DATA chunks and associations
using I-DATA chunks.</t>
<t>In <xref target='interleaving'/> this document specifies the user
message interleaving by defining the I-DATA chunk, the procedures to use it
and its interactions with other SCTP extensions.
Multiple stream schedulers are defined in <xref target='scheduler'/>
followed in <xref target='api'/> by describing an extension to the socket API
for using what is specified in this document.</t>
</section>

<section title="Conventions">
<t>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
<xref target='RFC2119'/>.</t>
</section>
</section>

<section anchor='interleaving'
         title="User Message Interleaving">
<!-- Add a Motivation section -->
<t>The protocol mechanisms described in this document allow the interleaving
of user messages sent on different streams. They do not support the interleaving
of multiple messages (ordered or unordered) sent on the same stream.</t>
<t>The interleaving of user messages is required for WebRTC Datachannels
as specified in <xref target='I-D.ietf-rtcweb-data-channel'/>.</t>
<t>An SCTP implementation supporting user message interleaving is REQUIRED
to support the coexistence of associations using DATA chunks and associations
using I-DATA chunks.
If an SCTP implementation supports user message interleaving and the Partial
Reliability extension described in <xref target='RFC3758'/> or the Stream
Reconfiguration Extension described in <xref target='RFC6525'/>,
it is REQUIRED to implement the corresponding changes specified in
<xref target='interactions'/>.</t>

<section title="The I-DATA Chunk Supporting User Message Interleaving">
<t>The following <xref target='i_data_chunk'/> shows the
new I-DATA chunk allowing user message interleaving.</t>
<figure title='I-DATA chunk format'
        anchor='i_data_chunk'>
<artwork>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 64   |  Res  |I|U|B|E|       Length = Variable       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              TSN                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Stream Identifier      |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Message Identifier                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Payload Protocol Identifier / Fragment Sequence Number     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/                           User Data                           /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>

<t>The only differences between the I-DATA chunk in
<xref target='i_data_chunk'/> and the DATA chunk defined in
<xref target='RFC4960'/> and <xref target='RFC7053'/> are the
addition of the new Message Identifier (MID) and the new
Fragment Sequence Number (FSN) and the
removal of the Stream Sequence Number (SSN).
The Payload Protocol Identifier (PPID) already defined for DATA chunks
in <xref target='RFC4960'/> and the new FSN are stored at the
same location of the packet using the B bit to determine which value is
stored at the location.
The length of the I-DATA chunk header is 20 bytes, which is 4 bytes more than
the length of the DATA chunk header defined in <xref target='RFC4960'/>
and <xref target='RFC7053'/>.</t>

<t>The old fields are:
<list style="hanging">
<t hangText="Res: 4 bits">
<vspace blankLines="0"/>
These bits are reserved.
They MUST be set to 0 by the sender and MUST be ignored by the receiver.</t>
<t hangText="I bit: 1 bit">
<vspace blankLines="0"/>
The (I)mmediate Bit, if set, indicates that the receiver SHOULD NOT delay the
sending of the corresponding SACK chunk.
Same as the I bit for DATA chunks as specified in <xref target='RFC7053'/>.</t>
<t hangText="U bit: 1 bit">
<vspace blankLines="0"/>
The (U)nordered bit, if set, indicates the user message is unordered.
Same as the U bit for DATA chunks as specified in <xref target='RFC4960'/>.</t>
<t hangText="B bit: 1 bit">
<vspace blankLines="0"/>
The (B)eginning fragment bit, if set, indicates the first fragment of a user
message.
Same as the B bit for DATA chunks as specified in <xref target='RFC4960'/>.</t>
<t hangText="E bit: 1 bit">
<vspace blankLines="0"/>
The (E)nding fragment bit, if set, indicates the last fragment of a user
message.
Same as the E bit for DATA chunks as specified in <xref target='RFC4960'/>.</t>
<t hangText="Length: 16 bits (unsigned integer)">
<vspace blankLines="0"/>
This field indicates the length of the DATA chunk in bytes from the beginning
of the type field to the end of the User Data field excluding any padding.
Similar to the Length for DATA chunks as specified in <xref target='RFC4960'/>.</t>
<t hangText="TSN: 32 bits (unsigned integer)">
<vspace blankLines="0"/>
This value represents the TSN for this I-DATA chunk.
Same as the TSN for DATA chunks as specified in <xref target='RFC4960'/>.</t>
<t hangText="Stream Identifier: 16 bits (unsigned integer)">
<vspace blankLines="0"/>
Identifies the stream to which the user data belongs.
Same as the Stream Identifier for DATA chunks as specified in
<xref target='RFC4960'/>.</t>
</list></t>

<t>The new fields are:
<list style="hanging">
<t hangText="Reserved: 16 bits (unsigned integer)">
<vspace blankLines="0"/>
This field is reserved.
It MUST be set to 0 by the sender and MUST be ignored by the receiver.</t>
<t hangText="Message Identifier (MID): 32 bits (unsigned integer)">
<vspace blankLines="0"/>
The MID is the same for all fragments of a user message, it is used to
determine which fragments (enumerated by the FSN) belong to the same user
message. For ordered user messages, the MID is also used by the SCTP receiver
to deliver the user messages in the correct order to the upper layer (similar
to the SSN of the DATA chunk defined in <xref target='RFC4960'/>).
The sender uses for each outgoing stream two counters,
one for ordered messages, one for unordered messages.
All of these counters are independent and initially 0.
They are incremented by 1 for each user message.
Please note that the serial number arithmetic defined in
<xref target='RFC1982'/> using SERIAL_BITS = 32 applies.
Therefore, the sender MUST NOT have more than 2**31 - 1 ordered messages for
each outgoing stream in flight and MUST NOT have more than 2**31 - 1 unordered
messages for each outgoing stream in flight.
A message is considered in flight, if at least on of its I-DATA chunks is not
acknowledged in a non-renegable way (i.e. not acknowledged by the cumulative
TSN Ack).
<!-- For ordered user messages, the lower 16 bit of the MID can be used as a SSN if
required. -->
Please note that the MID is in "network byte order", a.k.a. Big Endian.</t>
<t hangText="Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN): 32 bits (unsigned integer)">
<vspace blankLines="0"/>
If the B bit is set, this field contains the PPID of the user message.
Note that in this case, this field is not touched by an SCTP implementation;
therefore, its byte order is not necessarily in network byte order.
The upper layer is responsible for any byte order conversions to this field,
similar to the PPID of DATA chunks.
In this case the FSN is implicitly considered to be 0.
If the B bit is not set, this field contains the FSN.
The FSN is used to enumerate all fragments of a single user message, starting
from 0 and incremented by 1.
The last fragment of a message MUST have the E bit set.
Note that the FSN MAY wrap completely multiple times allowing arbitrarily large
user messages. For the FSN the serial number arithmetic defined in
<xref target='RFC1982'/> applies with SERIAL_BITS = 32.
Therefore, a sender MUST NOT have more than 2**31 - 1 fragments of a single user
message in flight. A fragment is considered in flight, if it is not
acknowledged in a non-renegable way.

Please note that the FSN is in "network byte order", a.k.a. Big Endian.</t>
</list></t>
</section>

<section title='Procedures'>
<t>This subsection describes how the support of the I-DATA chunk is negotiated
and how the I-DATA chunk is used by the sender and receiver.</t>
<t>The handling of the I bit for the I-DATA chunk corresponds to the handling
of the I bit for the DATA chunk described in <xref target='RFC7053'/>.</t>
<section title='Negotiation'>
<t>An SCTP end point indicates user message interleaving support by listing
the I-DATA Chunk within the Supported Extensions Parameter as defined in
<xref target='RFC5061'/>.
User message interleaving has been negotiated for an association if both end
points have indicated I-DATA support.</t>
<t>If user message interleaving support has been negotiated for an association,
I-DATA chunks MUST be used for all user messages and DATA-chunks MUST NOT be
used.
If user message interleaving support has not been negotiated for an association,
DATA chunks MUST be used for all user messages and I-DATA chunks MUST NOT be
used.</t>
<t>An end point implementing the socket API specified in
<xref target='RFC6458'/> MUST NOT indicate user message interleaving support
unless the user has requested its use (e.g. via the socket API, see
<xref target='socket_options'/>).
This constraint is made since the usage of this chunk requires that the
application is capable of handling interleaved messages upon reception within an
association.
This is not the default choice within the socket API
(see the SCTP_FRAGMENT_INTERLEAVE socket option in Section 8.1.20 of
<xref target='RFC6458'/>) thus the user MUST indicate to the
SCTP implementation its support for receiving completely interleaved messages.</t>
<t>Note that stacks that do not implement <xref target='RFC6458'/> may
use other methods to indicate interleaved message support and thus indicate the
support of user message interleaving.
The crucial point is that the SCTP stack MUST know that the application
can handle interleaved messages before indicating the I-DATA support.</t>
</section>

<section title='Sender Side Considerations'>
<t>The sender side usage of the I-DATA chunk is quite simple. Instead
of using the TSN for fragmentation purposes, the sender uses the
new FSN field to indicate which fragment number is being sent.
The first fragment MUST have the B bit set.
The last fragment MUST have the E bit set.
All other fragments MUST NOT have the B bit or E bit set.
All other properties of the existing SCTP DATA chunk also apply to
the I-DATA chunk, i.e. congestion control as well as receiver
window conditions MUST be observed as defined in <xref target='RFC4960'/>.</t>
<t>Note that the usage of this chunk  implies the late assignment of the
actual TSN to any chunk being sent. Each I-DATA chunk uses a single TSN.
This way messages from other streams may be interleaved with the
fragmented message. Please note that this is the only form of interleaving
support. For example, it is not possible to interleave multiple ordered
or unordered user messages from the same stream.</t>

<t>The sender MUST NOT process (move user data into I-DATA chunks and assign
a TSN to it) more than one user message in any given stream at any time.
At any time, a sender MAY process multiple user messages, each of them on
different streams.</t>

<t>The sender MUST assign TSNs to I-DATA chunks in a way that the receiver
can make progress.
One way to achieve this is to assign a higher TSN to the later fragments of a
user message and send out the I-DATA chunks such that the TSNs are in
sequence.</t>
</section>

<section title='Receiver Side Considerations'>
<t>Upon reception of an SCTP packet containing an I-DATA chunk whose
user message needs to be reassembled, the receiver MUST first use the SID to
identify the stream, consider the U bit to determine if it is part of an ordered
or unordered message, find the user message identified by the MID and finally
use the FSN for reassembly of the message and not the TSN.
The receiver MUST NOT make any assumption about the TSN assignments of the sender.
Note that a non-fragmented message is indicated by the fact that both the E and
B bits are set.
A message (either ordered or unordered) may be identified as being fragmented
whose E and B bits are not both set.</t>
<t>If I-DATA support has been negotiated for an association, the reception of
a DATA chunk is a violation of the above rules and therefore the receiver
of the DATA chunk MUST abort the association by sending an ABORT chunk.
The ABORT chunk MAY include the 'Protocol Violation' error cause.
The same applies if I-DATA support has not been negotiated for an association
and an I-DATA chunk is received.</t>
</section>
</section>

<section anchor='interactions'
         title='Interaction with other SCTP Extensions'>
<t>The usage of the I-DATA chunk might interfere with other SCTP extensions.
Future SCTP extensions MUST describe if and how they interfere with the
usage of I-DATA chunks. For the SCTP extensions already defined when this
document was published, the details are given in the following subsections.</t>

<section title='SCTP Partial Reliability Extension'>
<t>When the SCTP extension defined in <xref target='RFC3758'/> is used
in combination with the user message interleaving extension, the new
I-FORWARD-TSN chunk MUST be used instead of the FORWARD-TSN chunk.
The difference between the FORWARD-TSN and the I-FORWARD-TSN chunk is that
the 16-bit Stream Sequence Number (SSN) has been replaced by the 32-bit Message
Identifier (MID) and the largest skipped MID can also be provided for
unordered messages.
Therefore, the principle applied to ordered message when using FORWARD-TSN
chunks is applied to ordered and unordered messages when using I-FORWARD-TSN
chunks.</t>
<figure title='I-FORWARD-TSN chunk format'
        anchor='i_forward_tsn_chunk'>
<artwork>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 194  | Flags = 0x00  |      Length = Variable        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       New Cumulative TSN                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Stream Identifier       |          Reserved           |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Message Identifier                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Stream Identifier       |          Reserved           |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Message Identifier                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The old fields are:
<list style="hanging">
<t hangText="Flags: 8-bits (unsigned integer)">
<vspace blankLines="0"/>
These bits are reserved.
They MUST be set to 0 by the sender and MUST be ignored by the receiver.
Same as the Flags for FORWARD TSN chunks as specified in
<xref target='RFC3758'/>.</t>
<t hangText="Length: 16-bits (unsigned integer)">
<vspace blankLines="0"/>
This field holds the length of the chunk.
Similar to the Length for FORWARD TSN chunks as specified in
<xref target='RFC3758'/>.</t>
<t hangText="New Cumulative TSN: 32-bits (unsigned integer)">
<vspace blankLines="0"/>
This indicates the new cumulative TSN to the data receiver.
Same as the New Cumulative TSN for FORWARD TSN chunks as specified in
<xref target='RFC3758'/>.</t>
</list></t>
<t>The new fields are:
<list style="hanging">
<t hangText="Stream Identifier (SID): 16-bits (unsigned integer)">
<vspace blankLines="0"/>
This field holds the stream number this entry refers to.</t>
<t hangText="Reserved: 15 bits">
<vspace blankLines="0"/>
This field is reserved.
It MUST be set to 0 by the sender and MUST be ignored by the receiver.</t>
<t hangText="U bit: 1 bit">
<vspace blankLines="0"/>
The U bit specifies if the Message Identifier of this entry refers to
unordered messages (U bit is set) or ordered messages (U bit is not set).</t>
<t hangText="Message Identifier (MID): 32 bits (unsigned integer)">
<vspace blankLines="0"/>
This field holds the largest Message Identifier for ordered or unordered
messages indicated by the U bit that was skipped for the stream specified
by the Stream Identifier. For ordered messages this is similar to the
FORWARD-TSN chunk, just replacing the 16-bit SSN by the 32-bit MID.</t>
</list></t>
<t>Support for the I-FORWARD-TSN chunk is negotiated during the SCTP association
setup via the Supported Extensions Parameter as defined in
<xref target='RFC5061'/>. Only if both end points indicated their support of
user message interleaving and the I-FORWARD-TSN chunk, the partial reliability
extension is negotiated and can be used in combination with user message
interleaving.</t>
<t>The FORWARD-TSN chunk MUST be used in combination with the DATA chunk and
MUST NOT be used in combination with the I-DATA chunk.
The I-FORWARD-TSN chunk MUST be used in combination with the I-DATA chunk and
MUST NOT be used in combination with the DATA chunk.</t>
<t>If I-FORWARD-TSN support has been negotiated for an association, the
reception of a FORWARD-TSN chunk is a violation of the above rules and therefore
the receiver of the FORWARD-TSN chunk MUST abort the association by sending an
ABORT chunk.
The ABORT chunk MAY include the 'Protocol Violation' error cause.
The same applies if I-FORWARD-TSN support has not been negotiated for an
association and a FORWARD-TSN chunk is received.</t>
</section>

<section title='SCTP Stream Reconfiguration Extension'>
<t>When an association resets the SSN using the SCTP extension defined in
<xref target='RFC6525'/>, the two counters (one for the ordered messages,
one for the unordered messages) used for the MIDs MUST be reset to 0.</t>
<t>Since most schedulers, especially all schedulers supporting user
message interleaving, require late TSN assignment, it should be noted that the
implementation of <xref target='RFC6525'/> needs to handle this.</t>
</section>
</section>
</section>

<section anchor='scheduler'
         title="Stream Schedulers">
<t>This section defines several stream schedulers.
The stream schedulers may behave differently depending on whether user
message interleaving has been negotiated for the association or not.
An implementation MAY implement any subset of them.
If the implementation is used for WebRTC Datachannels as specified in
<xref target='I-D.ietf-rtcweb-data-channel'/> it MUST implement the
Weighted Fair Queueing Scheduler defined in <xref target='sctp_ss_wfq'/>.</t>
<t>The selection of the stream scheduler is done at the sender side. There
is no mechanism provided for signalling the stream scheduler being used
to the receiver side or even let the receiver side influence the selection
of the stream scheduler used at the sender side.</t>

<section anchor='sctp_ss_fcfs'
         title='First Come First Served Scheduler (SCTP_SS_FCFS)'>
<t>The simple first-come, first-served scheduler of user messages is used.
It just passes through the messages in the order in which they have been
delivered by the application. No modification of the order is done at all.
The usage of user message interleaving does not affect the sending of
the chunks, except that I-DATA chunks are used instead of DATA chunks.</t>
</section>
<section anchor='sctp_ss_rr'
         title='Round Robin Scheduler (SCTP_SS_RR)'>
<t>When not using user message interleaving, this scheduler provides a fair
scheduling based on the number of user messages by cycling around non-empty
stream queues. When using user message interleaving, this scheduler provides
a fair scheduling based on the number of I-DATA chunks by cycling around
non-empty stream queues.</t>
</section>
<section anchor='sctp_ss_rr_pkt'
         title='Round Robin Scheduler per Packet (SCTP_SS_RR_PKT)'>
<t>This is a round-robin scheduler, which only switches streams when
starting to fill a new packet.
It bundles only DATA or I-DATA chunks referring to the same stream in a packet.
This scheduler minimizes head-of-line blocking when a packet is lost because
only a single stream is affected.</t>
</section>
<section anchor='sctp_ss_prio'
         title='Priority Based Scheduler (SCTP_SS_PRIO)'>
<t>Scheduling of user messages with strict priorities is used.
The priority is configurable per outgoing SCTP stream.
Streams having a higher priority will be scheduled first and when multiple
streams have the same priority, the scheduling between them is implementation
dependent.
When using user message interleaving, the sending of large lower priority user
messages will not delay the sending of higher priority user messages.</t>
</section>
<section anchor='sctp_ss_fb'
         title='Fair Capacity Scheduler (SCTP_SS_FC)'>
<t>A fair capacity distribution between the streams is used.
This scheduler considers the lengths of the messages of each stream and
schedules them in a specific way to maintain an equal capacity for all
streams. The details are implementation dependent.
Using user message interleaving allows for a better realization of the
fair capacity usage.</t>
</section>
<section anchor='sctp_ss_wfq'
         title='Weighted Fair Queueing Scheduler (SCTP_SS_WFQ)'>
<t>A weighted fair queueing scheduler between the streams is used.
The weight is configurable per outgoing SCTP stream.
This scheduler considers the lengths of the messages of each stream and
schedules them in a specific way to use the capacity according to the given
weights.
If the weight of stream S1 is n times the weight of stream S2, the
scheduler should assign to stream S1 n times the capacity it assigns to
stream S2.
The details are implementation dependent.
Using user message interleaving allows for a better realization of the
capacity usage according to the given weights.</t>
<t>This scheduler in combination with user message interleaving is used for
WebRTC Datachannels as specified in
<xref target='I-D.ietf-rtcweb-data-channel'/>.</t>
</section>
</section>

<section title='Socket API Considerations'
         anchor='api'>
<t>This section describes how the socket API defined in
<xref target='RFC6458'/> is extended to allow applications to use the extension
described in this document.</t>
<t>Please note that this section is informational only.</t>

<section title="Exposure of the Stream Sequence Number (SSN)">
<t>The socket API defined in <xref target='RFC6458'/> defines several structures
in which the SSN of a received user message is exposed to the application.
The list of these structures includes:
<list style="hanging">
<t hangText="struct sctp_sndrcvinfo">
<vspace blankLines="0"/>
Specified in Section 5.3.2 SCTP Header Information Structure (SCTP_SNDRCV) of
<xref target='RFC6458'/> and marked as deprecated.</t>
<t hangText="struct sctp_extrcvinfo">
<vspace blankLines="0"/>
Specified in Section 5.3.3 Extended SCTP Header Information Structure
(SCTP_EXTRCV)of <xref target='RFC6458'/> and marked as deprecated.</t>
<t hangText="struct sctp_rcvinfo">
<vspace blankLines="0"/>
Specified in Section 5.3.5 SCTP Receive Information Structure (SCTP_RCVINFO)
of <xref target='RFC6458'/>.</t>
</list>
If user message interleaving is used, the lower order 16 bits of the MID are
used as the SSN when filling out these structures.</t>
</section>

<section title="SCTP_ASSOC_CHANGE Notification">
<t>When an SCTP_ASSOC_CHANGE notification (specified in Section 6.1.1 of
<xref target='RFC6458'/>) is delivered indicating a sac_state of SCTP_COMM_UP
or SCTP_RESTART for an SCTP association where both peers support the
I-DATA chunk, SCTP_ASSOC_SUPPORTS_INTERLEAVING should be listed in the sac_info
field.</t>
</section>

<section anchor='socket_options'
         title="Socket Options">

<texttable>
<ttcol align='left'>option name</ttcol>
<ttcol align='left'>data type</ttcol>
<ttcol align='center'>get</ttcol>
<ttcol align='center'>set</ttcol>
<c>SCTP_INTERLEAVING_SUPPORTED</c> <c>struct sctp_assoc_value </c> <c>X</c> <c>X</c>
<c>SCTP_STREAM_SCHEDULER      </c> <c>struct sctp_assoc_value </c> <c>X</c> <c>X</c>
<c>SCTP_STREAM_SCHEDULER_VALUE</c> <c>struct sctp_stream_value</c> <c>X</c> <c>X</c>
</texttable>

<section title="Enable or Disable the Support of User Message Interleaving (SCTP_INTERLEAVING_SUPPORTED)">
<t>This socket option allows the enabling or disabling of the negotiation
of user message interleaving support for future associations.
For existing associations it allows to query whether user message interleaving
support was negotiated or not on a particular association.</t>
<t>This socket option uses IPPROTO_SCTP as its level and
SCTP_INTERLEAVING_SUPPORTED as its name.
It can be used with getsockopt() and setsockopt().
The socket option value uses the following structure
defined in <xref target='RFC6458'/>:</t>
<figure>
<artwork>
struct sctp_assoc_value {
  sctp_assoc_t assoc_id;
  uint32_t assoc_value;
};
</artwork>
</figure>
<t><list style="hanging">
<t hangText="assoc_id:">
This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets, this parameter indicates upon which association
the user is performing an action.
The special sctp_assoc_t SCTP_FUTURE_ASSOC can also be used,
it is an error to use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.</t>
<t hangText="assoc_value:">
A non-zero value encodes the enabling of user message interleaving whereas
a value of 0 encodes the disabling of user message interleaving.</t>
</list></t>
<t>sctp_opt_info() needs to be extended to support SCTP_INTERLEAVING_SUPPORTED.</t>
<t>An application using user message interleaving should also set the fragment
interleave level to 2 by using the SCTP_FRAGMENT_INTERLEAVE socket option
specified in Section 8.1.20 of <xref target='RFC6458'/>.
This allows the interleaving of user messages from different streams.
Please note that it does not allow the interleaving of user messages
(ordered or unordered) on the same stream.
Failure to set this option can possibly lead to application deadlock.
Some implementations might therefore put some restrictions on setting
combinations of these values.
Setting the interleaving level to at least 2 before enabling the negotiation of
user message interleaving should work on all platforms.
Since the default fragment interleave level is not 2, user message interleaving
is disabled per default.</t>
</section>

<section title="Get or Set the Stream Scheduler (SCTP_STREAM_SCHEDULER)">
<t>A stream scheduler can be selected with the SCTP_STREAM_SCHEDULER
option for setsockopt(). The struct sctp_assoc_value is used to
specify the association for which the scheduler should be changed
and the value of the desired algorithm.</t>

<t>The definition of struct sctp_assoc_value is the same as in
<xref target="RFC6458"/>:</t>
<figure>
<artwork>
struct sctp_assoc_value {
  sctp_assoc_t assoc_id;
  uint32_t assoc_value;
};
</artwork>
</figure>
<t><list style='hanging'>
<t hangText="assoc_id:">
Holds the identifier for the association of which the scheduler should
be changed. The special SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be
used. This parameter is ignored for one-to-one style sockets.</t>

<t hangText="assoc_value:">
This specifies which scheduler is used. The following constants can be used:
<list style='hanging'>
<t hangText="SCTP_SS_DEFAULT:">
The default scheduler used by the SCTP implementation. Typical values are
SCTP_SS_FCFS or SCTP_SS_RR.</t>
<t hangText="SCTP_SS_FCFS:">
Use the scheduler specified in <xref target='sctp_ss_fcfs'/>.</t>
<t hangText="SCTP_SS_RR:">
Use the scheduler specified in <xref target='sctp_ss_rr'/>.</t>
<t hangText="SCTP_SS_RR_PKT:">
Use the scheduler specified in <xref target='sctp_ss_rr_pkt'/>.</t>
<t hangText="SCTP_SS_PRIO:">
Use the scheduler specified in <xref target='sctp_ss_prio'/>.
The priority can be assigned with the sctp_stream_value struct.
The higher the assigned value, the lower the priority, that is the default
value 0 is the highest priority and therefore the default scheduling will
be used if no priorities have been assigned.</t>
<t hangText="SCTP_SS_FB:">
Use the scheduler specified in <xref target='sctp_ss_fb'/>.</t>
<t hangText="SCTP_SS_WFQ:">
Use the scheduler specified in <xref target='sctp_ss_wfq'/>.
The weight can be assigned with the sctp_stream_value struct.</t>
</list></t>
</list></t>
<t>sctp_opt_info() needs to be extended to support SCTP_STREAM_SCHEDULER.</t>
</section>

<section title="Get or Set the Stream Scheduler Parameter (SCTP_STREAM_SCHEDULER_VALUE)">
<t>Some schedulers require additional information to be set for individual
streams as shown in the following table:</t>
<texttable>
<ttcol align='left'>name</ttcol>
<ttcol align='center'>per stream info</ttcol>
<c>SCTP_SS_DEFAULT</c>            <c>n/a</c>
<c>SCTP_SS_FCFS</c>               <c>no</c>
<c>SCTP_SS_RR</c>                 <c>no</c>
<c>SCTP_SS_RR_PKT</c>             <c>no</c>
<c>SCTP_SS_PRIO</c>               <c>yes</c>
<c>SCTP_SS_FB</c>                 <c>no</c>
<c>SCTP_SS_WFQ</c>                <c>yes</c>
</texttable>
<t>This is achieved with the SCTP_STREAM_SCHEDULER_VALUE option and the
corresponding struct sctp_stream_value.
The definition of struct sctp_stream_value is as follows:</t>
<figure>
<artwork>
struct sctp_stream_value {
  sctp_assoc_t assoc_id;
  uint16_t stream_id;
  uint16_t stream_value;
};
</artwork>
</figure>

<t><list style='hanging'>
<t hangText="assoc_id:">
Holds the identifier for the association of which the scheduler should
be changed. The special SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be
used. This parameter is ignored for one-to-one style sockets.</t>
<t hangText="stream_id:">
Holds the stream id of the stream for which additional information has
to be provided.</t>
<t hangText="stream_value:">
The meaning of this field depends on the scheduler specified. It is
ignored when the scheduler does not need additional information.</t>
</list></t>
<t>sctp_opt_info() needs to be extended to support SCTP_STREAM_SCHEDULER_VALUE.</t>
</section>
</section>
<section title="Explicit EOR Marking">
<t>Using explicit End of Record (EOR) marking for an SCTP association
supporting user message interleaving allows the user to interleave the sending
of user messages on different streams.</t>
</section>
</section>

<section title="IANA Considerations">
<t>[NOTE to RFC-Editor:
<list>
<t>"RFCXXXX" is to be replaced by the RFC number you assign this document.</t>
</list>
]</t>
<t>[NOTE to RFC-Editor:
<list>
<t>The suggested values for the chunk types and the chunk flags are tentative
and to be confirmed by IANA.</t>
</list>
]</t>
<t>This document (RFCXXXX) is the reference for all registrations
described in this section.</t>

<t>Two new chunk types have to be assigned by IANA.</t>
<section title="I-DATA Chunk">
<t>IANA should assign the chunk type for this chunk  from the pool of chunks
with the upper two bits set to '01'.
This requires an additional line in the "Chunk Types" registry for SCTP:</t>
<texttable>
<ttcol align='left'>ID Value</ttcol>
<ttcol align='left'>Chunk Type</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>64</c> <c>Payload Data supporting Interleaving (I-DATA)</c> <c>[RFCXXXX]</c>
</texttable>
<t>The registration table as defined in <xref target='RFC6096'/> for
the chunk flags of this chunk type is initially given by the following
table:</t>
<texttable>
<ttcol align='left'>Chunk Flag Value</ttcol>
<ttcol align='left'>Chunk Flag Name</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>0x01</c> <c>E bit     </c> <c>[RFCXXXX]</c>
<c>0x02</c> <c>B bit     </c> <c>[RFCXXXX]</c>
<c>0x04</c> <c>U bit     </c> <c>[RFCXXXX]</c>
<c>0x08</c> <c>I bit     </c> <c>[RFCXXXX]</c>
<c>0x10</c> <c>Unassigned</c> <c>         </c>
<c>0x20</c> <c>Unassigned</c> <c>         </c>
<c>0x40</c> <c>Unassigned</c> <c>         </c>
<c>0x80</c> <c>Unassigned</c> <c>         </c>
</texttable>
</section>
<section title="I-FORWARD-TSN Chunk">
<t>IANA should assign the chunk type for this chunk  from the pool of chunks
with the upper two bits set to '11'.
This requires an additional line in the "Chunk Types" registry for SCTP:</t>
<texttable>
<ttcol align='left'>ID Value</ttcol>
<ttcol align='left'>Chunk Type</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>194</c> <c>I-FORWARD-TSN</c> <c>[RFCXXXX]</c>
</texttable>
<t>The registration table as defined in <xref target='RFC6096'/> for
the chunk flags of this chunk type is initially empty.</t>
</section>
</section>

<section title="Security Considerations">
<t>This document does not add any additional security considerations
in addition to the ones given in <xref target='RFC4960'/> and
<xref target='RFC6458'/>.</t>
<t>It should be noted that the application has to consent that it is willing
to do the more complex reassembly support required for user message
interleaving.
When doing so, an application has to provide a reassembly buffer for each
incoming stream.
It has to protect itself against these buffers taking too many resources.
If user message interleaving is not used, only a single reassembly buffer needs
to be provided for each association.
But the application has to protect itself for excessive resource
usages there too.</t>
</section>

<section title='Acknowledgments'>
<t>The authors wish to thank
Benoit Claise,
Julian Cordes,
Spencer Dawkins,
Gorry Fairhurst,
Lennart Grahl,
Christer Holmberg,
Mirja Kuehlewind,
Marcelo Ricardo Leitner,
Karen E. Egede Nielsen,
Maksim Proshin,
Eric Rescorla,
Irene Ruengeler,
Felix Weinrank,
Michael Welzl,
Magnus Westerlund,
and Lixia Zhang
for their invaluable comments.</t>
<t>This work has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement No. 644334 (NEAT).
The views expressed are solely those of the author(s).</t>
</section>

</middle>

<back>
<references title='Normative References'>
<?rfc include="reference.RFC.1982" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.3758" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.5061" ?>
<?rfc include="reference.RFC.6096" ?>
<?rfc include="reference.RFC.6525" ?>
<?rfc include='reference.RFC.7053' ?>
</references>
<references title='Informative References'>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.6458" ?>
<?rfc include='reference.I-D.ietf-rtcweb-data-channel'?>
</references>
</back>
</rfc>