Skip to main content

Retransmit bit for SCTP DATA, I-DATA and SACK
draft-proshin-tsvwg-sctp-rtx-bit-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Maksim Proshin
Last updated 2019-12-02
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-proshin-tsvwg-sctp-rtx-bit-02
Internet Engineering Task Force                               M. Proshin
Internet-Draft                                                  Ericsson
Updates: 4960 (if approved)                            December 02, 2019
Intended status: Standards Track
Expires: June 4, 2020

             Retransmit bit for SCTP DATA, I-DATA and SACK
                  draft-proshin-tsvwg-sctp-rtx-bit-02

Abstract

   This document defines a method which helps an SCTP sender to
   understand when a received SACK acknowledges the original
   transmission of a TSN or its retransmission.  It is done by
   specifying a new bit, called Retransmit bit (R-bit), in the header of
   DATA, I-DATA and SACK chunks.  The bit is used when a TSN is
   retransmitted and returned back in the acknowledgement.  This
   document updates [RFC4960] if approved.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 4, 2020.

Copyright Notice

   Copyright (c) 2019 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

Proshin                   Expires June 4, 2020                  [Page 1]
Internet-Draft                                             December 2019

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Updates in SCTP Chunks Header . . . . . . . . . . . . . . . .   3
     3.1.  R-bit in DATA Chunk Header  . . . . . . . . . . . . . . .   3
     3.2.  R-bit in I-DATA Chunk Header  . . . . . . . . . . . . . .   4
     3.3.  R-bit in SACK Chunk Header  . . . . . . . . . . . . . . .   4
   4.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Negotiation . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Sender Side Considerations  . . . . . . . . . . . . . . .   6
     4.3.  Receiver Side Considerations  . . . . . . . . . . . . . .   7
     4.4.  Processing of SACK with and without R-bit . . . . . . . .   7
   5.  R-bit vs Duplicate TSN for Detection of Spurious
       Retransmission  . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Interoperability Considerations . . . . . . . . . . . . . . .   9
   7.  Socket API Considerations . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   SCTP which is defined in [RFC4960] is a reliable message-oriented
   protocol.  The SCTP sender splits user messages to DATA chunks and
   sends them to the receiver.  The SCTP receiver uses the SACK chunk to
   acknowledge incoming data.  The reliability in SCTP is achieved by
   the retransmission of DATA chunks which were not acknowledged.

   If a DATA chunk has been retransmitted at least once, at SACK
   reception SCTP cannot understand if the SACK was sent in response to
   the originally sent DATA or retransmitted one.  Thus, due to that
   ambiguity, [RFC4960] prohibits making RTT measurements.  Some other
   SCTP mechanisms such as loss recovery and congestion control are not
   accurate in that case either.

   This document describes a simple extension of the DATA and SACK
   chunks by a new bit, so called Retransmit bit (R-bit).  The sender
   sets the R-bit in the DATA chunk header when it retransmits a DATA
   and the receiver sets it in the SACK chunk header when a DATA with

Proshin                   Expires June 4, 2020                  [Page 2]
Internet-Draft                                             December 2019

   R-bit is acknowledged.  The sender can now distinguish when a SACK
   acknowledges the originally sent DATA or retransmitted one.  The
   extension requires support by the sender and the receiver.

   The mechanism described in this document is equally relevant for
   I-DATA chunk which is introduced in [RFC8260].

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.

3.  Updates in SCTP Chunks Header

3.1.  R-bit in DATA Chunk Header

   Figure 1 describes the extended DATA chunk header.

       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 = 0    | Res |R|I|U|B|E|           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              TSN                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Stream Identifier      |     Stream Sequence Number    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Payload Protocol Identifier                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                           User Data                           /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: Extended DATA chunk

   The only difference between the DATA chunk in Figure 1 and the DATA
   chunk defined in [RFC4960] is the addition of the R-bit in the flags
   field of the DATA chunk header.  [RFC4960] specified that bit as
   Reserved and that it should be set to 0 by the sender and ignored by
   the receiver.

Proshin                   Expires June 4, 2020                  [Page 3]
Internet-Draft                                             December 2019

3.2.  R-bit in I-DATA Chunk Header

   Figure 2 describes the extended DATA chunk header.

       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 |R|I|U|B|E|            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              TSN                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Stream Identifier      |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Message Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Payload Protocol Identifier / Fragment Sequence Number     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \                                                               \
      /                           User Data                           /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 2: Extended I-DATA chunk

   The only difference between the I-DATA chunk in Figure 2 and the
   I-DATA chunk defined in [RFC8260] is the addition of the R-bit in the
   flags field of the I-DATA chunk header.  [RFC8260] specified that bit
   as Reserved and that it should be set to 0 by the sender and ignored
   by the receiver.

3.3.  R-bit in SACK Chunk Header

   Figure 3 describes the extended SACK chunk header.

Proshin                   Expires June 4, 2020                  [Page 4]
Internet-Draft                                             December 2019

      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 = 3    |  Reserved   |R|      Chunk Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Cumulative TSN Ack                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Advertised Receiver Window Credit (a_rwnd)           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Number of Gap Ack Blocks = N  |  Number of Duplicate TSNs = X |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Gap Ack Block #1 Start       |   Gap Ack Block #1 End        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     \                              ...                              \
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Gap Ack Block #N Start      |  Gap Ack Block #N End         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Duplicate TSN 1                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                                               /
     \                              ...                              \
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Duplicate TSN X                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3: Extended SACK chunk

   The only difference between the SACK chunk in Figure 3 and the SACK
   chunk defined in [RFC4960] is the addition of the R-bit in the flags
   field of the SACK chunk header.  [RFC4960] specified that bit as
   Reserved and that it should be set to 0 by the sender and ignored by
   the receiver.

4.  Procedures

4.1.  Negotiation

   R-bit MUST NOT be used unless both SCTP peers negotiated its support.

   The following new optional parameter is added to the INIT and INIT
   ACK chunks to negotiate R-bit support during association setup:

Proshin                   Expires June 4, 2020                  [Page 5]
Internet-Draft                                             December 2019

      +----------------+-------------------------------------------+
      | Parameter Type | Parameter Name                            |
      +----------------+-------------------------------------------+
      | 0x8100         | Retransmit Bit Supported (RBIT-SUPPORTED) |
      +----------------+-------------------------------------------+

                                  Table 1

   The parameter format is the following:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Parameter Type = 0x8100     |    Parameter Length = 4      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 4: Format of RBIT-SUPPORTED

   Parameter Type: 2 bytes (unsigned integer)

      This value MUST be set to 0x8100 (33024).

   Parameter Length: 2 bytes (unsigned integer)

      This value MUST be set to 4.

   The RBIT-SUPPORTED parameter MAY be included once in the INIT or INIT
   ACK chunk if the sender wants to inform its peer that it supports
   R-bit.

   The new parameter type is encoded so that it requires the receiver to
   skip it and continue processing if the parameter is not recognized
   according to [RFC4960].

4.2.  Sender Side Considerations

   SCTP MUST NOT set the R-bit when it sends a DATA or I-DATA chunk
   first time.

   If R-bit support is negotiated as described in Section 4.1, SCTP
   SHOULD set the R-bit every time it retransmits a DATA or I-DATA
   chunk.  This is regardless of if the chunk is retransmitted on the
   same path or on an alternative one.

   Note that it is possible that the same SCTP packet includes DATA or
   I-DATA chunks with and without the R-bit set in case when SCTP
   bundles chunks which are marked for retransmission with chunks which
   are sent first time.  This is aligned with [RFC4960] which allows

Proshin                   Expires June 4, 2020                  [Page 6]
Internet-Draft                                             December 2019

   bundling of DATA chunks marked for retransmission with new DATA
   chunks.

   IMPLEMENTATION NOTE: According to [RFC4960] new DATA chunks always
   follow DATA chunks marked for retransmission when bundled in one
   packet.

4.3.  Receiver Side Considerations

   SCTP MUST NOT set the R-bit when it sends a SACK which acknowledges a
   DATA or I-DATA chunk without the R-bit set.  The delay for a SACK
   without the R-bit set is defined according to [RFC4960].

   When SCTP receives a packet with DATA or I-DATA chunk(s) with the
   R-bit set, it MUST immediately respond with a SACK with the R-bit set
   acknowledging only DATA or I-DATA chunks where the R-bit was set.  If
   the packet also contains DATA or I-DATA chunk(s) without the R-bit
   set, SCTP MUST NOT acknowledge them in the same SACK chunk.

   TBD: SACK with the R-bit bundled with SACK without the R-bit?  It may
   be useful.

4.4.  Processing of SACK with and without R-bit

   If a DATA or I-DATA was retransmitted and the corresponding SACK is
   received, SCTP can distinguish if the SACK acknowledges the original
   transmission or retransmission by checking the R-bit in the SACK.
   SCTP mechanisms which can be improved by that information include,
   but are not limited to, the following:

   o  RTO Calculation: [RFC4960] refers to Karn's algorithm and
      prohibits SCTP to make RTT measurements using packets that were
      retransmitted and for which it is ambiguous whether the reply was
      for the original transmission or retransmission(s).

   o  Path Failure Detection: [RFC4960] specifies that the sender may
      choose not to clear the path error counter if there is undesirable
      ambiguity when a DATA is retransmitted on an alternative path.

   o  SCTP-PF Operation in [RFC7829]: additionally to the path error
      counter case described in the previous bullet [RFC7829] also does
      not recommend to move a destination address in PF state back to
      the active state in case of ambiguity.

   o  Detection of spurious retransmissions: using R-bit SCTP can detect
      spurious retransmissions.  Namely, if a DATA was retransmitted and
      SACK acknowledging it does not include R-bit, it means that the
      retransmission was spurious.  Note that this is valid even if a

Proshin                   Expires June 4, 2020                  [Page 7]
Internet-Draft                                             December 2019

      DATA was retransmitted multiple times which makes this method more
      effective than detecting of spurious retransmissions based on
      DSACK.  When a spurious retransmission is detected, SCTP
      implementation may:

      *  Choose to revert the congestion control state.

      *  Choose to adjust RTO settings such as the RTO.Min value to
         mitigate further spurious retransmissions.

      *  Indicate the SCTP user.

   o  SCTP latency of retransmitted data: If the original DATA is lost,
      the SCTP receiver will immediately acknowledge the retransmitted
      DATA.

   o  Calculation of Maximum Ack Delay: SCTP implementations can support
      a technique for calculating of Maximum Ack Delay in run-time which
      is impossible to do properly in case of retransmissions.  With
      R-bit SCTP can distinguish if the SACK acknowledges the original
      transmission or retransmission and can measure the delay even for
      a retransmitted DATA.

   o  Measurement of packet loss: R-bit can be used for passive loss
      rate calculation.

   TBD: dup TSN but without R-bit: SACK loss or reordering: Can be used
   somehow?

   Note that this document does not solve the problem when the same DATA
   or I-DATA chunk is retransmitted multiple times.  In that case, when
   SCTP receives a SACK without the R-bit set, it can ensure that the
   SACK acknowledges the original transmission but when SCTP receives a
   SACK with the R-bit set, it cannot distinguish which retransmission
   is actually acknowledged.  Such limitation is not considered as
   severe because multiple retransmissions of the same DATA or I-DATA is
   a corner case and, if it happens, SCTP transmission is anyway
   inefficient.

5.  R-bit vs Duplicate TSN for Detection of Spurious Retransmission

   The SACK chunk according to [RFC4960] contains the Duplicate TSN
   field which is used by the receiver to indicate TSNs received
   multiple times.  This could happen due to spurious retransmissions or
   if packets were duplicated in the network between endpoints.  The
   Duplicate TSN field in the SACK chunk can also be used by the sender
   to detect spurious retransmissions in some cases.  However, the

Proshin                   Expires June 4, 2020                  [Page 8]
Internet-Draft                                             December 2019

   mechanism based on the Duplicate TSN field would have serious
   limitations compared to the mechanism based on R-bit:

   o  With R-bit the SCTP sender has an exclusive match between DATA and
      SACK while in case of the Duplicate TSN it is not guaranteed.
      Thus, if the original or retranmitted DATA is lost or one of the
      SACKs is lost or the packets were retransmitted, the SCTP sender
      cannot rely on the Duplicate TSN field.

   o  Even in those cases where the sender could rely on the Duplicate
      TSN, it would need to wait the second SACK to detect the spurious
      retransmission, while with R-bit, the sender can detect it as soon
      as the first SACK is received.

   o  In case of the Duplicate TSN the SCTP sender needs to keep
      information about the retransmitted TSN until the second SACK is
      received or during some time period which impacts memory usage and
      SCTP performance and complicates implementation.

6.  Interoperability Considerations

   This document does not introduce any interoperability issues.
   Section 4.1 requires both ends to negotiate R-bit support before its
   usage.  [RFC4960] requires the receiver of a DATA or SACK chunk with
   the R-bit set to ignore the bit if it is not recognized.  [RFC8260]
   requires the receiver of an I-DATA chunk with the R-bit set to ignore
   the bit if it is not recognized.

7.  Socket API Considerations

   This document does not address any changes to the socket API defined
   in [RFC6458].

8.  Acknowledgements

   TBD

9.  IANA Considerations

   [NOTE to RFC-Editor:

      "RFCXXXX" is to be replaced by the RFC number you assign this
      document.

   ]

   IANA should assign 33024 (0x8100) as a new parameter type to SCTP.

Proshin                   Expires June 4, 2020                  [Page 9]
Internet-Draft                                             December 2019

   Following the chunk flag registration procedure defined in [RFC6096],
   IANA should register a new bit, the R-bit, for the DATA chunk.  The
   suggested value is 0x10 and the reference should be RFCXXXX.

   This requires an update of the "DATA Chunk Flags" registry for SCTP:

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+
            | 0x01             | E bit           | [RFC4960] |
            | 0x02             | B bit           | [RFC4960] |
            | 0x04             | U bit           | [RFC4960] |
            | 0x08             | I bit           | [RFC7053] |
            | 0x10             | R bit           | RFCXXXX   |
            | 0x20             | Unassigned      |           |
            | 0x40             | Unassigned      |           |
            | 0x80             | Unassigned      |           |
            +------------------+-----------------+-----------+

                                  Table 2

   Following the chunk flag registration procedure defined in [RFC6096],
   IANA should register a new bit, the R-bit, for the SACK chunk.  The
   suggested value is 0x01 and the reference should be RFCXXXX.

   This requires an update of the "SACK Chunk Flags" registry for SCTP:

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+
            | 0x01             | R bit           | RFCXXXX   |
            | 0x02             | Unassigned      |           |
            | 0x04             | Unassigned      |           |
            | 0x08             | Unassigned      |           |
            | 0x10             | Unassigned      |           |
            | 0x20             | Unassigned      |           |
            | 0x40             | Unassigned      |           |
            | 0x80             | Unassigned      |           |
            +------------------+-----------------+-----------+

                                  Table 3

   Following the chunk flag registration procedure defined in [RFC6096],
   IANA should register a new bit, the R-bit, for the I-DATA chunk.  The
   suggested value is 0x10 and the reference should be RFCXXXX.

   This requires an update of the "I-DATA Chunk Flags" registry for
   SCTP:

Proshin                   Expires June 4, 2020                 [Page 10]
Internet-Draft                                             December 2019

            +------------------+-----------------+-----------+
            | Chunk Flag Value | Chunk Flag Name | Reference |
            +------------------+-----------------+-----------+
            | 0x01             | E bit           | [RFC8260] |
            | 0x02             | B bit           | [RFC8260] |
            | 0x04             | U bit           | [RFC8260] |
            | 0x08             | I bit           | [RFC8260] |
            | 0x10             | R bit           | RFCXXXX   |
            | 0x20             | Unassigned      |           |
            | 0x40             | Unassigned      |           |
            | 0x80             | Unassigned      |           |
            +------------------+-----------------+-----------+

                                  Table 4

10.  Security Considerations

   This document does not introduce any additional security
   considerations in addition to the ones described in [RFC4960] and
   [RFC8260].

11.  References

11.1.  Normative References

   [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>.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,
              <https://www.rfc-editor.org/info/rfc4960>.

   [RFC8260]  Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
              "Stream Schedulers and User Message Interleaving for the
              Stream Control Transmission Protocol", RFC 8260,
              DOI 10.17487/RFC8260, November 2017,
              <https://www.rfc-editor.org/info/rfc8260>.

11.2.  Informative References

   [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>.

Proshin                   Expires June 4, 2020                 [Page 11]
Internet-Draft                                             December 2019

   [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>.

   [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>.

   [RFC7829]  Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K.
              Nielsen, "SCTP-PF: A Quick Failover Algorithm for the
              Stream Control Transmission Protocol", RFC 7829,
              DOI 10.17487/RFC7829, April 2016,
              <https://www.rfc-editor.org/info/rfc7829>.

   [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>.

Author's Address

   Maksim Proshin
   Ericsson
   Kistavaegen 25
   Stockholm   164 80
   Sweden

   Email: mproshin@tieto.mera.ru

Proshin                   Expires June 4, 2020                 [Page 12]