doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc8260.txt b/doc/rfc/rfc8260.txt
new file mode 100644
index 0000000..9144f7a
--- /dev/null
+++ b/doc/rfc/rfc8260.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        R. Stewart
+Request for Comments: 8260                                 Netflix, Inc.
+Category: Standards Track                                      M. Tuexen
+ISSN: 2070-1721                         Muenster Univ. of Appl. Sciences
+                                                               S. Loreto
+                                                                Ericsson
+                                                           R. Seggelmann
+                                     Metafinanz Informationssysteme GmbH
+                                                           November 2017
+
+
+            Stream Schedulers and User Message Interleaving
+              for the Stream Control Transmission Protocol
+
+Abstract
+
+   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 data channels.
+
+   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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8260.
+
+
+
+
+
+
+
+
+
+Stewart, et al.              Standards Track                    [Page 1]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.              Standards Track                    [Page 2]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+     1.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
+     1.2.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   6
+   2.  User Message Interleaving . . . . . . . . . . . . . . . . . .   6
+     2.1.  The I-DATA Chunk Supporting User Message Interleaving . .   7
+     2.2.  Procedures  . . . . . . . . . . . . . . . . . . . . . . .   9
+       2.2.1.  Negotiation . . . . . . . . . . . . . . . . . . . . .  10
+       2.2.2.  Sender-Side Considerations  . . . . . . . . . . . . .  10
+       2.2.3.  Receiver-Side Considerations  . . . . . . . . . . . .  11
+     2.3.  Interaction with Other SCTP Extensions  . . . . . . . . .  11
+       2.3.1.  SCTP Partial Reliability Extension  . . . . . . . . .  11
+       2.3.2.  SCTP Stream Reconfiguration Extension . . . . . . . .  13
+   3.  Stream Schedulers . . . . . . . . . . . . . . . . . . . . . .  14
+     3.1.  First-Come, First-Served Scheduler (SCTP_SS_FCFS) . . . .  14
+     3.2.  Round-Robin Scheduler (SCTP_SS_RR)  . . . . . . . . . . .  14
+     3.3.  Round-Robin Scheduler per Packet (SCTP_SS_RR_PKT) . . . .  14
+     3.4.  Priority-Based Scheduler (SCTP_SS_PRIO) . . . . . . . . .  14
+     3.5.  Fair Capacity Scheduler (SCTP_SS_FC)  . . . . . . . . . .  15
+     3.6.  Weighted Fair Queueing Scheduler (SCTP_SS_WFQ)  . . . . .  15
+   4.  Socket API Considerations . . . . . . . . . . . . . . . . . .  15
+     4.1.  Exposure of the Stream Sequence Number (SSN)  . . . . . .  15
+     4.2.  SCTP_ASSOC_CHANGE Notification  . . . . . . . . . . . . .  16
+     4.3.  Socket Options  . . . . . . . . . . . . . . . . . . . . .  16
+       4.3.1.  Enable or Disable the Support of User Message
+               Interleaving (SCTP_INTERLEAVING_SUPPORTED)  . . . . .  16
+       4.3.2.  Get or Set the Stream Scheduler
+               (SCTP_STREAM_SCHEDULER) . . . . . . . . . . . . . . .  17
+       4.3.3.  Get or Set the Stream Scheduler Parameter
+               (SCTP_STREAM_SCHEDULER_VALUE) . . . . . . . . . . . .  18
+     4.4.  Explicit EOR Marking  . . . . . . . . . . . . . . . . . .  19
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
+     5.1.  I-DATA Chunk  . . . . . . . . . . . . . . . . . . . . . .  19
+     5.2.  I-FORWARD-TSN Chunk . . . . . . . . . . . . . . . . . . .  20
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .  22
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  22
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.              Standards Track                    [Page 3]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+1.  Introduction
+
+1.1.  Overview
+
+   When SCTP [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 signaling messages
+   in the style of Session Initiation Protocol (SIP) [RFC3261] may also
+   need to use SCTP, and a message that is a single Maximum Transmission
+   Unit (MTU) 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 [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:
+
+   1.  As an identifier for DATA chunks to provide a reliable transfer.
+
+   2.  As an identifier for the sequence of fragments to allow
+       reassembly.
+
+   3.  As a sequence number allowing up to 2**16 - 1 Stream Sequence
+       Numbers (SSNs) outstanding.
+
+   The protocol requires all fragments of a user message to have
+   consecutive TSNs.  This document allows an SCTP sender to interleave
+   different user messages.
+
+   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 or not
+   user message interleaving has been negotiated for the association.
+
+   Figure 1 illustrates the behavior 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 chunks using TSN 0
+   to TSN 8.  Please note that the use of such a scheduler implies late
+
+
+
+
+
+
+
+Stewart, et al.              Standards Track                    [Page 4]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   TSN assignment, but it can be used with an implementation that is
+   compliant with [RFC4960] and 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.
+
+   +---+---+---+
+   |    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  |
+                                  +-------+
+
+     Figure 1: Round-Robin Scheduler without User Message Interleaving
+
+   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), and 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 that have the same
+   MID and the same ordering property.  The TSN is only used for the
+   reliable transfer in combination with Selective Acknowledgment (SACK)
+   chunks.
+
+   In addition, the MID is also used for ensuring ordered delivery
+   instead of using the stream sequence number (the I-DATA chunk omits
+   an SSN).
+
+   Figure 2 illustrates the behavior of an interleaving round-robin
+   stream scheduler using I-DATA chunks.
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.              Standards Track                    [Page 5]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
++---+---+---+
+|    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    |
+                                     +-----------+
+
+      Figure 2: Round-Robin Scheduler with User Message Interleaving
+
+   The support of the I-DATA chunk is negotiated during the association
+   setup using the Supported Extensions Parameter, as defined in
+   [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.
+
+   In Section 2, 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.  Section 3 defines multiple
+   stream schedulers, and Section 4 describes an extension to the socket
+   API for using the mechanism specified in this document.
+
+1.2.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  User Message Interleaving
+
+   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.
+
+
+
+Stewart, et al.              Standards Track                    [Page 6]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   The interleaving of user messages is required for WebRTC data
+   channels, as specified in [DATA-CHAN].
+
+   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 [RFC3758] or the Stream Reconfiguration
+   Extension described in [RFC6525], it is REQUIRED to implement the
+   corresponding changes specified in Section 2.3.
+
+2.1.  The I-DATA Chunk Supporting User Message Interleaving
+
+   The following Figure 3 shows the new I-DATA chunk allowing user
+   message interleaving.
+
+    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                           /
+   \                                                               \
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 3: I-DATA Chunk Format
+
+   The only differences between the I-DATA chunk in Figure 3 and the
+   DATA chunk defined in [RFC4960] and [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), which is already defined for DATA
+   chunks in [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 [RFC4960] and [RFC7053].
+
+
+
+
+
+Stewart, et al.              Standards Track                    [Page 7]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   The old fields are:
+
+   Res: 4 bits
+      These bits are reserved.  They MUST be set to 0 by the sender and
+      MUST be ignored by the receiver.
+
+   I bit: 1 bit
+      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 [RFC7053].
+
+   U bit: 1 bit
+      The (U)nordered bit, if set, indicates the user message is
+      unordered.  Same as the U bit for DATA chunks, as specified in
+      [RFC4960].
+
+   B bit: 1 bit
+      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 [RFC4960].
+
+   E bit: 1 bit
+      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 [RFC4960].
+
+   Length: 16 bits (unsigned integer)
+      This field indicates the length in bytes of the DATA chunk 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 [RFC4960].
+
+   TSN: 32 bits (unsigned integer)
+      This value represents the TSN for this I-DATA chunk.  Same as the
+      TSN for DATA chunks, as specified in [RFC4960].
+
+   Stream Identifier: 16 bits (unsigned integer)
+      Identifies the stream to which the user data belongs.  Same as the
+      Stream Identifier for DATA chunks, as specified in [RFC4960].
+
+   The new fields are:
+
+   Reserved: 16 bits (unsigned integer)
+      This field is reserved.  It MUST be set to 0 by the sender and
+      MUST be ignored by the receiver.
+
+
+
+
+
+
+Stewart, et al.              Standards Track                    [Page 8]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   Message Identifier (MID): 32 bits (unsigned integer)
+      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 [RFC4960]).  The sender uses two counters for
+      each outgoing stream: one for ordered messages and 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 [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 one of its I-DATA chunks is not acknowledged in
+      a way that cannot be reneged (i.e., not acknowledged by the
+      cumulative TSN Ack).  Please note that the MID is in "network byte
+      order", a.k.a.  Big Endian.
+
+   Payload Protocol Identifier (PPID) / Fragment Sequence Number (FSN):
+      32 bits (unsigned integer)
+      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, thus allowing arbitrarily large user messages.
+      For the FSN, the serial number arithmetic defined in [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
+      way that cannot be reneged.  Please note that the FSN is in
+      "network byte order", a.k.a.  Big Endian.
+
+2.2.  Procedures
+
+   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.
+
+   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 [RFC7053].
+
+
+
+Stewart, et al.              Standards Track                    [Page 9]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+2.2.1.  Negotiation
+
+   An SCTP endpoint indicates user message interleaving support by
+   listing the I-DATA chunk within the Supported Extensions Parameter,
+   as defined in [RFC5061].  User message interleaving has been
+   negotiated for an association if both endpoints have indicated I-DATA
+   support.
+
+   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.
+
+   An endpoint implementing the socket API specified in [RFC6458] MUST
+   NOT indicate user message interleaving support unless the user has
+   requested its use (e.g., via the socket API; see Section 4.3).  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 [RFC6458]); thus, the user MUST indicate to the
+   SCTP implementation its support for receiving completely interleaved
+   messages.
+
+   Note that stacks that do not implement [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.
+
+2.2.2.  Sender-Side Considerations
+
+   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 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 [RFC4960].
+
+   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.
+
+
+
+Stewart, et al.              Standards Track                   [Page 10]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   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.
+
+   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.
+
+2.2.3.  Receiver-Side Considerations
+
+   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 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) whose E and B bits are not both set may
+   be identified as being fragmented.
+
+   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.
+
+2.3.  Interaction with Other SCTP Extensions
+
+   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.
+
+2.3.1.  SCTP Partial Reliability Extension
+
+   When the SCTP extension defined in [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
+
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 11]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   provided for unordered messages.  Therefore, the principle applied to
+   ordered messages when using FORWARD-TSN chunks is applied to ordered
+   and unordered messages when using I-FORWARD-TSN chunks.
+
+    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                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 4: I-FORWARD-TSN Chunk Format
+
+   The old fields are:
+
+   Flags: 8 bits (unsigned integer)
+      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 [RFC3758].
+
+   Length: 16 bits (unsigned integer)
+      This field holds the length of the chunk.  Similar to the Length
+      for FORWARD TSN chunks, as specified in [RFC3758].
+
+   New Cumulative TSN: 32 bits (unsigned integer)
+      This indicates the New Cumulative TSN to the data receiver.  Same
+      as the New Cumulative TSN for FORWARD TSN chunks, as specified in
+      [RFC3758].
+
+   The new fields are:
+
+   Stream Identifier (SID): 16 bits (unsigned integer)
+      This field holds the stream number this entry refers to.
+
+
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 12]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   Reserved: 15 bits
+      This field is reserved.  It MUST be set to 0 by the sender and
+      MUST be ignored by the receiver.
+
+   U bit: 1 bit
+      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).
+
+   Message Identifier (MID): 32 bits (unsigned integer)
+      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.
+
+   Support for the I-FORWARD-TSN chunk is negotiated during the SCTP
+   association setup via the Supported Extensions Parameter, as defined
+   in [RFC5061].  The partial reliability extension is negotiated and
+   can be used in combination with user message interleaving only if
+   both endpoints indicated their support of user message interleaving
+   and the I-FORWARD-TSN chunk.
+
+   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.
+
+   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.
+
+2.3.2.  SCTP Stream Reconfiguration Extension
+
+   When an association resets the SSN using the SCTP extension defined
+   in [RFC6525], the two counters (one for the ordered messages, one for
+   the unordered messages) used for the MIDs MUST be reset to 0.
+
+   Since most schedulers, especially all schedulers supporting user
+   message interleaving, require late TSN assignment, it should be noted
+   that the implementation of [RFC6525] needs to handle this.
+
+
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 13]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+3.  Stream Schedulers
+
+   This section defines several stream schedulers.  The stream
+   schedulers may behave differently depending on whether or not user
+   message interleaving has been negotiated for the association.  An
+   implementation MAY implement any subset of them.  If the
+   implementation is used for WebRTC data channels, as specified in
+   [DATA-CHAN], it MUST implement the Weighted Fair Queueing Scheduler
+   defined in Section 3.6.
+
+   The selection of the stream scheduler is done at the sender side.
+   There is no mechanism provided for signaling the stream scheduler
+   being used to the receiver side or even for letting the receiver side
+   influence the selection of the stream scheduler used at the sender
+   side.
+
+3.1.  First-Come, First-Served Scheduler (SCTP_SS_FCFS)
+
+   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.
+
+3.2.  Round-Robin Scheduler (SCTP_SS_RR)
+
+   When not interleaving user messages, this scheduler provides a fair
+   scheduling based on the number of user messages by cycling around
+   non-empty stream queues.  When interleaving user messages, this
+   scheduler provides a fair scheduling based on the number of I-DATA
+   chunks by cycling around non-empty stream queues.
+
+3.3.  Round-Robin Scheduler per Packet (SCTP_SS_RR_PKT)
+
+   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.
+
+3.4.  Priority-Based Scheduler (SCTP_SS_PRIO)
+
+   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
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 14]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   dependent.  When the scheduler interleaves user messages, the sending
+   of large, lower-priority user messages will not delay the sending of
+   higher-priority user messages.
+
+3.5.  Fair Capacity Scheduler (SCTP_SS_FC)
+
+   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.  interleaving
+   user messages allows for a better realization of the fair capacity
+   usage.
+
+3.6.  Weighted Fair Queueing Scheduler (SCTP_SS_WFQ)
+
+   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.
+   Interleaving user messages allows for a better realization of the
+   capacity usage according to the given weights.
+
+   This scheduler, in combination with user message interleaving, is
+   used for WebRTC data channels, as specified in [DATA-CHAN].
+
+4.  Socket API Considerations
+
+   This section describes how the socket API defined in [RFC6458] is
+   extended to allow applications to use the extension described in this
+   document.
+
+   Please note that this section is informational only.
+
+4.1.  Exposure of the Stream Sequence Number (SSN)
+
+   The socket API defined in [RFC6458] defines several structures in
+   which the SSN of a received user message is exposed to the
+   application.  The list of these structures includes:
+
+   struct sctp_sndrcvinfo
+      Specified in Section 5.3.2 of [RFC6458] and marked as deprecated.
+
+   struct sctp_extrcvinfo
+      Specified in Section 5.3.3 of [RFC6458] and marked as deprecated.
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 15]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   struct sctp_rcvinfo
+      Specified in Section 5.3.5 of [RFC6458].
+
+   If user message interleaving is used, the lower-order 16 bits of the
+   MID are used as the SSN when filling out these structures.
+
+4.2.  SCTP_ASSOC_CHANGE Notification
+
+   When an SCTP_ASSOC_CHANGE notification (specified in Section 6.1.1 of
+   [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.
+
+4.3.  Socket Options
+
+   +-----------------------------+-------------------------+-----+-----+
+   | Option Name                 | Data Type               | Get | Set |
+   +-----------------------------+-------------------------+-----+-----+
+   | SCTP_INTERLEAVING_SUPPORTED | struct sctp_assoc_value |  X  |  X  |
+   | SCTP_STREAM_SCHEDULER       | struct sctp_assoc_value |  X  |  X  |
+   | SCTP_STREAM_SCHEDULER_VALUE | struct                  |  X  |  X  |
+   |                             | sctp_stream_value       |     |     |
+   +-----------------------------+-------------------------+-----+-----+
+
+4.3.1.  Enable or Disable the Support of User Message Interleaving
+        (SCTP_INTERLEAVING_SUPPORTED)
+
+   This socket option allows the enabling or disabling of the
+   negotiation of user message interleaving support for future
+   associations.  For existing associations, it allows for querying
+   whether or not user message interleaving support was negotiated on a
+   particular association.
+
+   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 [RFC6458]:
+
+   struct sctp_assoc_value {
+     sctp_assoc_t assoc_id;
+     uint32_t assoc_value;
+   };
+
+
+
+
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 16]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   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.
+
+   assoc_value:  A non-zero value encodes the enabling of user message
+      interleaving, whereas a value of zero encodes the disabling of
+      user message interleaving.
+
+   sctp_opt_info() needs to be extended to support
+   SCTP_INTERLEAVING_SUPPORTED.
+
+   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 [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.
+
+4.3.2.  Get or Set the Stream Scheduler (SCTP_STREAM_SCHEDULER)
+
+   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.
+
+   The definition of struct sctp_assoc_value is the same as in
+   [RFC6458]:
+
+   struct sctp_assoc_value {
+     sctp_assoc_t assoc_id;
+     uint32_t assoc_value;
+   };
+
+   assoc_id:  Holds the identifier of the association for 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.
+
+
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 17]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   assoc_value:  This specifies which scheduler is used.  The following
+      constants can be used:
+
+      SCTP_SS_DEFAULT:  The default scheduler used by the SCTP
+         implementation.  Typical values are SCTP_SS_FCFS or SCTP_SS_RR.
+
+      SCTP_SS_FCFS:  Use the scheduler specified in Section 3.1.
+
+      SCTP_SS_RR:  Use the scheduler specified in Section 3.2.
+
+      SCTP_SS_RR_PKT:  Use the scheduler specified in Section 3.3.
+
+      SCTP_SS_PRIO:  Use the scheduler specified in Section 3.4.  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.
+
+      SCTP_SS_FB:  Use the scheduler specified in Section 3.5.
+
+      SCTP_SS_WFQ:  Use the scheduler specified in Section 3.6.  The
+         weight can be assigned with the sctp_stream_value struct.
+
+   sctp_opt_info() needs to be extended to support
+   SCTP_STREAM_SCHEDULER.
+
+4.3.3.  Get or Set the Stream Scheduler Parameter
+        (SCTP_STREAM_SCHEDULER_VALUE)
+
+   Some schedulers require additional information to be set for
+   individual streams as shown in the following table:
+
+                   +-----------------+-----------------+
+                   | Name            | Per-Stream Info |
+                   +-----------------+-----------------+
+                   | SCTP_SS_DEFAULT |       n/a       |
+                   | SCTP_SS_FCFS    |        no       |
+                   | SCTP_SS_RR      |        no       |
+                   | SCTP_SS_RR_PKT  |        no       |
+                   | SCTP_SS_PRIO    |       yes       |
+                   | SCTP_SS_FB      |        no       |
+                   | SCTP_SS_WFQ     |       yes       |
+                   +-----------------+-----------------+
+
+
+
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 18]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   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:
+
+   struct sctp_stream_value {
+     sctp_assoc_t assoc_id;
+     uint16_t stream_id;
+     uint16_t stream_value;
+   };
+
+   assoc_id:  Holds the identifier of the association for 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.
+
+   stream_id:  Holds the identifier of the stream for which additional
+      information has to be provided.
+
+   stream_value:  The meaning of this field depends on the scheduler
+      specified.  It is ignored when the scheduler does not need
+      additional information.
+
+   sctp_opt_info() needs to be extended to support
+   SCTP_STREAM_SCHEDULER_VALUE.
+
+4.4.  Explicit EOR Marking
+
+   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.
+
+5.  IANA Considerations
+
+   Two new chunk types have been assigned by IANA.
+
+5.1.  I-DATA Chunk
+
+   IANA has assigned the chunk type for this chunk from the pool of
+   chunks with the upper two bits set to '01'.  This appears in the
+   "Chunk Types" registry for SCTP as follows:
+
+   +----------+--------------------------------------------+-----------+
+   | ID Value | Chunk Type                                 | Reference |
+   +----------+--------------------------------------------+-----------+
+   | 64       | Payload Data supporting Interleaving       | RFC 8260  |
+   |          | (I-DATA)                                   |           |
+   +----------+--------------------------------------------+-----------+
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 19]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+   The registration table (as defined in [RFC6096]) for the chunk flags
+   of this chunk type is initially as follows:
+
+            +------------------+-----------------+-----------+
+            | Chunk Flag Value | Chunk Flag Name | Reference |
+            +------------------+-----------------+-----------+
+            | 0x01             | E bit           | RFC 8260  |
+            | 0x02             | B bit           | RFC 8260  |
+            | 0x04             | U bit           | RFC 8260  |
+            | 0x08             | I bit           | RFC 8260  |
+            | 0x10             | Unassigned      |           |
+            | 0x20             | Unassigned      |           |
+            | 0x40             | Unassigned      |           |
+            | 0x80             | Unassigned      |           |
+            +------------------+-----------------+-----------+
+
+5.2.  I-FORWARD-TSN Chunk
+
+   IANA has assigned the chunk type for this chunk from the pool of
+   chunks with the upper two bits set to '11'.  This appears in the
+   "Chunk Types" registry for SCTP as follows:
+
+                 +----------+---------------+-----------+
+                 | ID Value | Chunk Type    | Reference |
+                 +----------+---------------+-----------+
+                 | 194      | I-FORWARD-TSN | RFC 8260  |
+                 +----------+---------------+-----------+
+
+   The registration table (as defined in [RFC6096]) for the chunk flags
+   of this chunk type is initially empty.
+
+6.  Security Considerations
+
+   This document does not add any additional security considerations in
+   addition to the ones given in [RFC4960] and [RFC6458].
+
+   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.
+
+
+
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 20]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              DOI 10.17487/RFC1982, August 1996,
+              <https://www.rfc-editor.org/info/rfc1982>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3758]  Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+              Conrad, "Stream Control Transmission Protocol (SCTP)
+              Partial Reliability Extension", RFC 3758,
+              DOI 10.17487/RFC3758, May 2004,
+              <https://www.rfc-editor.org/info/rfc3758>.
+
+   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
+              RFC 4960, DOI 10.17487/RFC4960, September 2007,
+              <https://www.rfc-editor.org/info/rfc4960>.
+
+   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
+              Kozuka, "Stream Control Transmission Protocol (SCTP)
+              Dynamic Address Reconfiguration", RFC 5061,
+              DOI 10.17487/RFC5061, September 2007,
+              <https://www.rfc-editor.org/info/rfc5061>.
+
+   [RFC6096]  Tuexen, M. and R. Stewart, "Stream Control Transmission
+              Protocol (SCTP) Chunk Flags Registration", RFC 6096,
+              DOI 10.17487/RFC6096, January 2011,
+              <https://www.rfc-editor.org/info/rfc6096>.
+
+   [RFC6525]  Stewart, R., Tuexen, M., and P. Lei, "Stream Control
+              Transmission Protocol (SCTP) Stream Reconfiguration",
+              RFC 6525, DOI 10.17487/RFC6525, February 2012,
+              <https://www.rfc-editor.org/info/rfc6525>.
+
+   [RFC7053]  Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-
+              IMMEDIATELY Extension for the Stream Control Transmission
+              Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013,
+              <https://www.rfc-editor.org/info/rfc7053>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 21]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+7.2.  Informative References
+
+   [DATA-CHAN]
+              Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
+              Channels", Work in Progress,
+              draft-ietf-rtcweb-data-channel-13, January 2015.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <https://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC6458]  Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
+              Yasevich, "Sockets API Extensions for the Stream Control
+              Transmission Protocol (SCTP)", RFC 6458,
+              DOI 10.17487/RFC6458, December 2011,
+              <https://www.rfc-editor.org/info/rfc6458>.
+
+Acknowledgments
+
+   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.
+
+   This work has received funding from the European Union's Horizon 2020
+   research and innovation program under grant agreement No. 644334
+   (NEAT).  The views expressed are solely those of the authors.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 22]
+
+RFC 8260         Stream Schedulers and the I-DATA Chunk    November 2017
+
+
+Authors' Addresses
+
+   Randall R. Stewart
+   Netflix, Inc.
+   Chapin, SC  29036
+   United States of America
+
+   Email: randall@lakerest.net
+
+
+   Michael Tuexen
+   Muenster University of Applied Sciences
+   Stegerwaldstrasse 39
+   48565 Steinfurt
+   Germany
+
+   Email: tuexen@fh-muenster.de
+
+
+   Salvatore Loreto
+   Ericsson
+   Torshamnsgatan 21
+   164 80 Stockholm
+   Sweden
+
+   Email: Salvatore.Loreto@ericsson.com
+
+
+   Robin Seggelmann
+   Metafinanz Informationssysteme GmbH
+   Leopoldstrasse 146
+   80804 Muenchen
+   Germany
+
+   Email: rfc@robin-seggelmann.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stewart, et al.              Standards Track                   [Page 23]
+