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

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.

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 7, 2019.

Copyright Notice

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

Table of Contents

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

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

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.

   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:

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 bundling of DATA chunks marked for retransmission with new DATA chunks.

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:

• 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).
• 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.
• 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.
• TBD: If a spurious retransmission is detected then SCTP may recover its state.

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

6. Socket API Considerations

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

7. Acknowledgements

TBD

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

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:

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:

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:

9. Security Considerations

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

10. References

10.1. Normative References

10.2. Informative References

Author's Address