idnits 2.17.1 draft-proshin-tsvwg-sctp-rtx-bit-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4960, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4960, updated by this document, for RFC5378 checks: 2006-02-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 04, 2018) is 1969 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6096 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 7053 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Proshin 3 Internet-Draft Ericsson 4 Updates: 4960 (if approved) December 04, 2018 5 Intended status: Standards Track 6 Expires: June 7, 2019 8 Retransmit bit for SCTP DATA, I-DATA and SACK 9 draft-proshin-tsvwg-sctp-rtx-bit-00 11 Abstract 13 This document defines a method which helps an SCTP sender to 14 understand when a received SACK acknowledges the original 15 transmission of a TSN or its retransmission. It is done by 16 specifying a new bit, called Retransmit bit (R-bit), in the header of 17 DATA, I-DATA and SACK chunks. The bit is used when a TSN is 18 retransmitted and returned back in the acknowledgement. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 7, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Updates in SCTP Chunks Header . . . . . . . . . . . . . . . . 3 57 3.1. R-bit in DATA Chunk Header . . . . . . . . . . . . . . . 3 58 3.2. R-bit in I-DATA Chunk Header . . . . . . . . . . . . . . 3 59 3.3. R-bit in SACK Chunk Header . . . . . . . . . . . . . . . 4 60 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Sender Side Considerations . . . . . . . . . . . . . . . 6 63 4.3. Receiver Side Considerations . . . . . . . . . . . . . . 7 64 4.4. Processing of SACK with and without R-bit . . . . . . . . 7 65 5. Interoperability Considerations . . . . . . . . . . . . . . . 8 66 6. Socket API Considerations . . . . . . . . . . . . . . . . . . 8 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 10.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 SCTP which is defined in [RFC4960] is a reliable message-oriented 78 protocol. The SCTP sender splits user messages to DATA chunks and 79 sends them to the receiver. The SCTP receiver uses the SACK chunk to 80 acknowledge incoming data. The reliability in SCTP is achieved by 81 the retransmission of DATA chunks which were not acknowledged. 83 If a DATA chunk has been retransmitted at least once, at SACK 84 reception SCTP cannot understand if the SACK was sent in response to 85 the originally sent DATA or retransmitted one. Thus, due to that 86 ambiguity, [RFC4960] prohibits making RTT measurements. Some other 87 SCTP mechanisms such as loss recovery and congestion control are not 88 accurate in that case either. 90 This document describes a simple extension of the DATA and SACK 91 chunks by a new bit, so called Retransmit bit (R-bit). The sender 92 sets the R-bit in the DATA chunk header when it retransmits a DATA 93 and the receiver sets it in the SACK chunk header when a DATA with 94 R-bit is acknowledged. The sender can now distinguish when a SACK 95 acknowledges the originally sent DATA or retransmitted one. The 96 extension requires support by the sender and the receiver. 98 The mechanism described in this document is equally relevant for 99 I-DATA chunk which is introduced in [RFC8260]. 101 2. Conventions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [[RFC8174]] when, and only when, they appear in all 107 capitals, as shown here. 109 3. Updates in SCTP Chunks Header 111 3.1. R-bit in DATA Chunk Header 113 Figure 1 describes the extended DATA chunk header. 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Type = 0 | Res |R|I|U|B|E| Length | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | TSN | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Stream Identifier | Stream Sequence Number | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Payload Protocol Identifier | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 \ \ 127 / User Data / 128 \ \ 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Figure 1: Extended DATA chunk 133 The only difference between the DATA chunk in Figure 1 and the DATA 134 chunk defined in [RFC4960] is the addition of the R-bit in the flags 135 field of the DATA chunk header. [RFC4960] specified that bit as 136 Reserved and that it should be set to 0 by the sender and ignored by 137 the receiver. 139 3.2. R-bit in I-DATA Chunk Header 141 Figure 2 describes the extended DATA chunk header. 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Type = 64 | Res |R|I|U|B|E| Length | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | TSN | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Stream Identifier | Reserved | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Message Identifier | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Payload Protocol Identifier / Fragment Sequence Number | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 \ \ 157 / User Data / 158 \ \ 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 2: Extended I-DATA chunk 163 The only difference between the I-DATA chunk in Figure 2 and the 164 I-DATA chunk defined in [RFC8260] is the addition of the R-bit in the 165 flags field of the I-DATA chunk header. [RFC8260] specified that bit 166 as Reserved and that it should be set to 0 by the sender and ignored 167 by the receiver. 169 3.3. R-bit in SACK Chunk Header 171 Figure 3 describes the extended SACK chunk header. 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Type = 3 | Reserved |R| Chunk Length | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Cumulative TSN Ack | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Advertised Receiver Window Credit (a_rwnd) | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Gap Ack Block #1 Start | Gap Ack Block #1 End | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 / / 187 \ ... \ 188 / / 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Gap Ack Block #N Start | Gap Ack Block #N End | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Duplicate TSN 1 | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 / / 195 \ ... \ 196 / / 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Duplicate TSN X | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 3: Extended SACK chunk 203 The only difference between the SACK chunk in Figure 3 and the SACK 204 chunk defined in [RFC4960] is the addition of the R-bit in the flags 205 field of the SACK chunk header. [RFC4960] specified that bit as 206 Reserved and that it should be set to 0 by the sender and ignored by 207 the receiver. 209 4. Procedures 211 4.1. Negotiation 213 R-bit MUST NOT be used unless both SCTP peers negotiated its support. 215 The following new optional parameter is added to the INIT and INIT 216 ACK chunks to negotiate R-bit support during association setup: 218 +----------------+-------------------------------------------+ 219 | Parameter Type | Parameter Name | 220 +----------------+-------------------------------------------+ 221 | 0x8100 | Retransmit Bit Supported (RBIT-SUPPORTED) | 222 +----------------+-------------------------------------------+ 224 Table 1 226 The parameter format is the following: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Parameter Type = 0x8100 | Parameter Length = 4 | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 4: Format of RBIT-SUPPORTED 236 Parameter Type: 2 bytes (unsigned integer) 238 This value MUST be set to 0x8100 (33024). 240 Parameter Length: 2 bytes (unsigned integer) 242 This value MUST be set to 4. 244 The RBIT-SUPPORTED parameter MAY be included once in the INIT or INIT 245 ACK chunk if the sender wants to inform its peer that it supports 246 R-bit. 248 The new parameter type is encoded so that it requires the receiver to 249 skip it and continue processing if the parameter is not recognized 250 according to [RFC4960]. 252 4.2. Sender Side Considerations 254 SCTP MUST NOT set the R-bit when it sends a DATA or I-DATA chunk 255 first time. 257 If R-bit support is negotiated as described in Section 4.1, SCTP 258 SHOULD set the R-bit every time it retransmits a DATA or I-DATA 259 chunk. This is regardless of if the chunk is retransmitted on the 260 same path or on an alternative one. 262 Note that it is possible that the same SCTP packet includes DATA or 263 I-DATA chunks with and without the R-bit set in case when SCTP 264 bundles chunks which are marked for retransmission with chunks which 265 are sent first time. This is aligned with [RFC4960] which allows 266 bundling of DATA chunks marked for retransmission with new DATA 267 chunks. 269 4.3. Receiver Side Considerations 271 SCTP MUST NOT set the R-bit when it sends a SACK which acknowledges a 272 DATA or I-DATA chunk without the R-bit set. The delay for a SACK 273 without the R-bit set is defined according to [RFC4960]. 275 When SCTP receives a packet with DATA or I-DATA chunk(s) with the 276 R-bit set, it MUST immediately respond with a SACK with the R-bit set 277 acknowledging only DATA or I-DATA chunks where the R-bit was set. If 278 the packet also contains DATA or I-DATA chunk(s) without the R-bit 279 set, SCTP MUST NOT acknowledge them in the same SACK chunk. 281 TBD: SACK with the R-bit bundled with SACK without the R-bit? It may 282 be useful. 284 4.4. Processing of SACK with and without R-bit 286 If a DATA or I-DATA was retransmitted and the corresponding SACK is 287 received, SCTP can distinguish if the SACK acknowledges the original 288 transmission or retransmission by checking the R-bit in the SACK. 289 SCTP mechanisms which can be improved by that information include, 290 but are not limited to, the following: 292 o RTO Calculation: [RFC4960] refers to Karn's algorithm and 293 prohibits SCTP to make RTT measurements using packets that were 294 retransmitted and for which it is ambiguous whether the reply was 295 for the original transmission or retransmission(s). 297 o Path Failure Detection: [RFC4960] specifies that the sender may 298 choose not to clear the path error counter if there is undesirable 299 ambiguity when a DATA is retransmitted on an alternative path. 301 o SCTP-PF Operation in [RFC7829]: additionally to the path error 302 counter case described in the previous bullet [RFC7829] also does 303 not recommend to move a destination address in PF state back to 304 the active state in case of ambiguity. 306 o TBD: If a spurious retransmission is detected then SCTP may 307 recover its state. 309 Note that this document does not solve the problem when the same DATA 310 or I-DATA chunk is retransmitted multiple times. In that case, when 311 SCTP receives a SACK with the R-bit set, it cannot distinguish which 312 retransmission is actually acknowledged. Such limitation is not 313 considered as severe because multiple retransmissions of the same 314 DATA or I-DATA is a corner case and, if it happens, SCTP transmission 315 is anyway inefficient. 317 5. Interoperability Considerations 319 This document does not introduce any interoperability issues. 320 Section 4.1 requires both ends to negotiate R-bit support before its 321 usage. [RFC4960] requires the receiver of a DATA or SACK chunk with 322 the R-bit set to ignore the bit if it is not recognized. [RFC8260] 323 requires the receiver of an I-DATA chunk with the R-bit set to ignore 324 the bit if it is not recognized. 326 6. Socket API Considerations 328 This document does not address any changes to the socket API defined 329 in [RFC6458]. 331 7. Acknowledgements 333 TBD 335 8. IANA Considerations 337 [NOTE to RFC-Editor: 339 "RFCXXXX" is to be replaced by the RFC number you assign this 340 document. 342 ] 344 IANA should assign 33024 (0x8100) as a new parameter type to SCTP. 346 Following the chunk flag registration procedure defined in [RFC6096], 347 IANA should register a new bit, the R-bit, for the DATA chunk. The 348 suggested value is 0x10 and the reference should be RFCXXXX. 350 This requires an update of the "DATA Chunk Flags" registry for SCTP: 352 +------------------+-----------------+-----------+ 353 | Chunk Flag Value | Chunk Flag Name | Reference | 354 +------------------+-----------------+-----------+ 355 | 0x01 | E bit | [RFC4960] | 356 | 0x02 | B bit | [RFC4960] | 357 | 0x04 | U bit | [RFC4960] | 358 | 0x08 | I bit | [RFC7053] | 359 | 0x10 | R bit | RFCXXXX | 360 | 0x20 | Unassigned | | 361 | 0x40 | Unassigned | | 362 | 0x80 | Unassigned | | 363 +------------------+-----------------+-----------+ 365 Table 2 367 Following the chunk flag registration procedure defined in [RFC6096], 368 IANA should register a new bit, the R-bit, for the SACK chunk. The 369 suggested value is 0x01 and the reference should be RFCXXXX. 371 This requires an update of the "SACK Chunk Flags" registry for SCTP: 373 +------------------+-----------------+-----------+ 374 | Chunk Flag Value | Chunk Flag Name | Reference | 375 +------------------+-----------------+-----------+ 376 | 0x01 | R bit | RFCXXXX | 377 | 0x02 | Unassigned | | 378 | 0x04 | Unassigned | | 379 | 0x08 | Unassigned | | 380 | 0x10 | Unassigned | | 381 | 0x20 | Unassigned | | 382 | 0x40 | Unassigned | | 383 | 0x80 | Unassigned | | 384 +------------------+-----------------+-----------+ 386 Table 3 388 Following the chunk flag registration procedure defined in [RFC6096], 389 IANA should register a new bit, the R-bit, for the I-DATA chunk. The 390 suggested value is 0x10 and the reference should be RFCXXXX. 392 This requires an update of the "I-DATA Chunk Flags" registry for 393 SCTP: 395 +------------------+-----------------+-----------+ 396 | Chunk Flag Value | Chunk Flag Name | Reference | 397 +------------------+-----------------+-----------+ 398 | 0x01 | E bit | [RFC8260] | 399 | 0x02 | B bit | [RFC8260] | 400 | 0x04 | U bit | [RFC8260] | 401 | 0x08 | I bit | [RFC8260] | 402 | 0x10 | R bit | RFCXXXX | 403 | 0x20 | Unassigned | | 404 | 0x40 | Unassigned | | 405 | 0x80 | Unassigned | | 406 +------------------+-----------------+-----------+ 408 Table 4 410 9. Security Considerations 412 This document does not introduce any additional security 413 considerations in addition to the ones described in [RFC4960] and 414 [RFC8260]. 416 10. References 418 10.1. Normative References 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, 423 . 425 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 426 RFC 4960, DOI 10.17487/RFC4960, September 2007, 427 . 429 [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 430 "Stream Schedulers and User Message Interleaving for the 431 Stream Control Transmission Protocol", RFC 8260, 432 DOI 10.17487/RFC8260, November 2017, 433 . 435 10.2. Informative References 437 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 438 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 439 DOI 10.17487/RFC6096, January 2011, 440 . 442 [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 443 Yasevich, "Sockets API Extensions for the Stream Control 444 Transmission Protocol (SCTP)", RFC 6458, 445 DOI 10.17487/RFC6458, December 2011, 446 . 448 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 449 IMMEDIATELY Extension for the Stream Control Transmission 450 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 451 . 453 [RFC7829] Nishida, Y., Natarajan, P., Caro, A., Amer, P., and K. 454 Nielsen, "SCTP-PF: A Quick Failover Algorithm for the 455 Stream Control Transmission Protocol", RFC 7829, 456 DOI 10.17487/RFC7829, April 2016, 457 . 459 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 460 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 461 May 2017, . 463 Author's Address 465 Maksim Proshin 466 Ericsson 467 Kistavaegen 25 468 Stockholm 164 80 469 Sweden 471 Email: mproshin@tieto.mera.ru