idnits 2.17.1 draft-natarajan-tsvwg-sctp-nrsack-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 823. 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 abstract seems to contain references ([RFC4960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 25, 2008) is 5904 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Natarajan 3 Internet-Draft P. Amer 4 Intended status: Standards Track E. Yilmaz 5 Expires: August 28, 2008 University of Delaware 6 R. Stewart 7 Cisco Systems, Inc. 8 J. Iyengar 9 Connecticut College 10 February 25, 2008 12 Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP 13 draft-natarajan-tsvwg-sctp-nrsack-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 28, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 Stream Control Transmission Protocol (SCTP) [RFC4960] specifies 47 Selective Acknowledgements (SACKs) to allow a transport layer data 48 receiver to acknowledge DATA chunks which arrive out-of-order. In 49 SCTP, SACK information is advisory because the data receiver is 50 permitted to renege; that is, later discard a DATA chunk which 51 previously has been SACKed. Since delivery of a SACKed out-of-order 52 DATA chunk is not guaranteed, a copy of this DATA chunk MUST be kept 53 in the data sender's retransmission queue until this DATA chunk is 54 cumulatively acked. 56 This document specifies Non-Renegable Selective Acknowledgements (NR- 57 SACKs), an extension to SCTP's acknowledgment mechanism. NR-SACKs 58 enable a data receiver to explicitly acknowledge out-of-order DATA 59 chunks that have been delivered to the receiving application. 60 (Recall that, in SCTP, out-of-order data sometimes can be delivered.) 61 NR-SACKs also enable a data receiver to indicate any out-of-order 62 DATA chunks on which the receiver guarantees never to renege. As 63 opposed to SACKed DATA chunks, a sender can consider NR-SACKed DATA 64 chunks as never requiring retransmission, thus freeing space in the 65 data sender's retransmission queue sooner. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4. The New Chunk Type: Non-Renegable SACK (NR-SACK) . . . . . . . 6 73 5. An Illustrative Example . . . . . . . . . . . . . . . . . . . 11 74 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 6.1. Sending an NR-SACK chunk . . . . . . . . . . . . . . . . . 15 76 6.2. Receiving an NR-SACK Chunk . . . . . . . . . . . . . . . . 17 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 84 Intellectual Property and Copyright Statements . . . . . . . . . . 21 86 1. Introduction 88 In providing end-to-end reliable transport layer data transfer, SCTP 89 specifies Cumulative Acknowledgements (ACKs), Selective ACKs (SACKs), 90 and Duplicate Selective ACKs (D-SACKs). These three types of acks 91 are carried in the following fields of the SACK chunk, respectively: 92 Cumulative TSN Ack, Gap Ack Block, and Duplicate TSN. In this 93 document, we refer to the Cumulative TSN Ack as the "cum-ack", the 94 selective Gap Ack Blocks as "gap-acks", and the Duplicate TSN 95 selective acks as "dup-TSN reports". 97 Gap-acks acknowledge DATA chunks that arrive out-of-order to a 98 transport layer data receiver. A gap-ack in SCTP is advisory, in 99 that, while it notifies a data sender about the reception of 100 indicated DATA chunks, the data receiver is permitted to later 101 discard DATA chunks that it previously had gap-acked. Discarding a 102 previously gap-acked DATA chunk is known as "reneging." Because of 103 the possibility of reneging in SCTP, any gap-acked DATA chunk MUST 104 NOT be removed from the data sender's retransmission queue until the 105 DATA chunk is later cum-acked. 107 Situations exist when a data receiver knows that reneging on a 108 particular out-of-order DATA chunk will never take place, such as 109 (but not limited to) after an out-of-order DATA chunk is delivered to 110 the receiving application. This document describes an extension to 111 SCTP to allow for Non-Renegable Selective Acknowledgments (NR-SACKs.) 112 A new NR-SACK chunk type is described that allows this extension to 113 be implemented. 115 The NR-SACK chunk is an extension of the existing SACK chunk. 116 Several fields are identical, including the Cumulative TSN Ack, the 117 Advertised Receiver Window Credit (a_rwnd), Gap Ack Blocks, and 118 Duplicate TSNs. These fields have the same semantics as described in 119 [RFC4960]. 121 NR-SACKs extend SACKs by also identifying out-of-order DATA chunks 122 that a receiver either: (1) has delivered to its receiving 123 application, or (2) takes full responsibility to eventually deliver 124 to its receiving application. These out-of-order DATA chunks are 125 "non-renegable." Non-Renegable data are reported in the NR Gap Ack 126 Block field of the NR-SACK chunk as described in Section 4.1. We 127 refer to non-renegable selective acknowledgements as "nr-gap-acks." 129 When an out-of-order DATA chunk is nr-gap-acked, the data sender no 130 longer needs to keep that particular DATA chunk in its retransmission 131 queue, thus allowing the data sender to free up its buffer space 132 sooner than if the DATA chunk were only gap-acked. NR-SACKs are 133 expected to improve throughput, particularly in multi-streamed SCTP 134 associations where out-of-order data often can be delivered, at the 135 trade-off of requiring additional processing of acknowledgement 136 information at both the data receiver and data sender [Natarajan]. 138 An SCTP message is encapsulated within a single DATA chunk or within 139 multiple DATA chunks in case of fragmentation. In this document 140 without loss of generality, each application message maps to a single 141 transport layer DATA chunk, and delivering a DATA chunk to a 142 receiving application means delivering the message carried within the 143 DATA chunk to a receiving application. 145 SCTP divides an end-to-end association into independent logical data 146 streams (a.k.a. multistreaming.) A DATA chunk that arrives in- 147 sequence within a stream can be delivered to the receiving 148 application even if the DATA chunk is out-of-order relative to the 149 association's overall flow of data. These out-of-order DATA chunks 150 are "deliverable." By definition, a DATA chunk marked for unordered 151 delivery also is "deliverable" to the receiving application 152 immediately upon reception, regardless of its position within the 153 overall flow of data. 155 With current SACKs in SCTP, it is not possible for a data receiver to 156 inform a data sender if or when a particular out-of-order 157 "deliverable" DATA chunk has been "delivered" to the receiving 158 application. Thus the data sender MUST keep a copy of every gap- 159 acked out-of-order DATA chunk(s) in the data sender's retransmission 160 queue until the DATA chunk is cum-acked. This use of the data 161 sender's retransmission queue is wasteful. Given the receiving 162 application has received the data, the data sender has no reason to 163 keep this data in its retransmission queue. Yet, the sending 164 transport layer keeps the data because no mechanism currently exists 165 to indicate which out-of-order DATA chunks have been delivered. 166 (Note: once a DATA chunk is delivered to the receiving application, 167 it is impossible for the data receiver to renege that DATA chunk.) 169 If NR-SACKs are used, the data receiver MAY include the TSN of a 170 delivered out-of-order DATA chunk in an NR-SACK to inform the data 171 sender that the delivery has occurred, allowing the data sender to 172 remove the copy of the delivered DATA chunk from the data sender's 173 retransmission queue even before the DATA chunk is cum-acked. 175 2. Conventions 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 3. Negotiation 183 Before sending/receiving NR-SACKs, both peer endpoints MUST agree on 184 using NR-SACKs. This agreement MUST be negotiated during association 185 establishment. NR-SACK is an extension to the core SCTP, and SCTP 186 extensions that an endpoint supports are reported to the peer 187 endpoint in Supported Extensions Parameter during association 188 establishment (see Section 4.2.7 of [RFC5061].) The Supported 189 Extensions Parameter consists of a list of non-standard Chunk Types 190 that are supported by the sender. 192 An endpoint supporting the NR-SACK extension MUST list the NR-SACK 193 chunk in the Supported Extensions Parameter carried in the INIT or 194 INIT-ACK chunk, depending on whether the endpoint initiates or 195 responds to the initiation of the association. If the NR-SACK chunk 196 type ID is listed in the Chunk Types List of the Supported Extensions 197 Parameter, then the receiving endpoint MUST assume that the NR-SACK 198 chunk is supported by the sending endpoint. 200 Both endpoints MUST support NR-SACKs for either endpoint to send an 201 NR-SACK. If an endpoint which tries to establish an association with 202 a remote endpoint does not list NR-SACK in the Supported Extensions 203 Parameter carried in INIT chunk, then both endpoints of the 204 association MUST NOT use NR-SACKs. After association establishment, 205 an endpoint MUST NOT renegotiate the use of NR-SACKs. 207 Once both endpoints indicate during association establishment that 208 they support the NR-SACK extension, each endpoint SHOULD acknowledge 209 received DATA chunks with NR-SACK chunks, and not SACK chunks. That 210 is, throughout an SCTP association, both endpoints SHOULD send either 211 SACK chunks or NR-SACK chunks, but not a mixture of the two. 213 4. The New Chunk Type: Non-Renegable SACK (NR-SACK) 215 Table 1 illustrates a new chunk type that will be used to transfer 216 NR-SACK information. 218 Chunk Type Chunk Name 219 -------------------------------------------------------------- 220 0x10 Non-Renegable Selective Acknowledgment (NR-SACK) 222 Table 1: NR-SACK Chunk 224 As the NR-SACK chunk replaces the SACK chunk, many of the SACK chunk 225 fields are preserved in the NR-SACK chunk. These fields preserved in 226 the NR-SACK chunk have the same semantics with the corresponding SACK 227 chunk fields, as defined in [RFC4960], Section 3.3.4. For 228 completeness, we describe all fields of the NR-SACK chunk, including 229 those that are identical in the SACK chunk. 231 All arithmetic operations discussed in this document are based on 232 "Serial Number Arithmetic" as described in Section 1.6 of [RFC4960]. 234 Similar to the SACK chunk, the NR-SACK chunk is sent to a peer 235 endpoint to (1) acknowledge DATA chunks received in-order, (2) 236 acknowledge DATA chunks received out-of-order, and (3) indicate DATA 237 chunks received more than once (i.e., duplicate.) In addition, the 238 NR-SACK chunk also informs the peer endpoint of non-renegable out-of- 239 order DATA chunks. 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type = 0x10 | Reserved |A| Chunk Length | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Cumulative TSN Ack | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Advertised Receiver Window Credit (a_rwnd) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Number of Gap Ack Blocks = N |Number of NR Gap Ack Blocks = M| 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Number of Duplicate TSNs = X | Reserved | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Gap Ack Block #1 Start | Gap Ack Block #1 End | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 / / 257 \ ... \ 258 / / 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Gap Ack Block #N Start | Gap Ack Block #N End | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | NR Gap Ack Block #1 Start | NR Gap Ack Block #1 End | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 / / 265 \ ... \ 266 / / 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | NR Gap Ack Block #M Start | NR Gap Ack Block #M End | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Duplicate TSN 1 | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 / / 273 \ ... \ 274 / / 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Duplicate TSN X | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Type: 8 bits 281 This field holds the IANA defined chunk type for NR-SACK chunk. The 282 suggested value of this field for IANA is 0x10. 284 Reserved: 7 bits [Same as SACK chunk] 286 Currently not used. It is recommended a sender set all bits to zero 287 on transmit, and a receiver ignore this field. 289 A bit: 1 bit 291 The (A)ll bit, if set to '1', indicates that all of the out-of-order 292 data blocks acknowledged in this NR-SACK chunk are non-renegable. If 293 (A)ll bit is set to '1', then Number of Gap Ack Blocks (N) MUST be 294 set to '0' (for example, see CASE-3 in Section 5.) 296 Chunk Length: 16 bits (unsigned integer) [Same as SACK chunk] 298 This value represents the size of the chunk in bytes including the 299 Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. 301 Cumulative TSN Ack: 32 bits (unsigned integer) [Same as SACK chunk] 303 The value of the Cumulative TSN Ack is the last TSN received before a 304 break in the sequence of received TSNs occurs. The next TSN value 305 following the Cumulative TSN Ack has not yet been received at the 306 endpoint sending the NR-SACK. 308 Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned 309 integer) [Same as SACK chunk] 311 Indicates the updated receive buffer space in bytes of the sender of 312 this NR-SACK, see Section 6.2.1 of [RFC4960] for details. 314 Number of Gap Ack Blocks (N): 16 bits (unsigned integer) [Same as 315 SACK chunk] 317 Indicates the number of Gap Ack Blocks included in this NR-SACK. If 318 the (A)ll bit is set to one, meaning that all out-of-order data 319 blocks are non-renegable, then the Number of NR Gap Ack Blocks MUST 320 be set to '0'. 322 Number of NR Gap Ack Blocks (M): 16 bits (unsigned integer) 324 Indicates the number of Non-Renegable Gap Ack Blocks included in this 325 NR-SACK. 327 Number of Duplicate TSNs (X): 16 bits [Same as SACK chunk] 329 Contains the number of duplicate TSNs the endpoint has received. 330 Each duplicate TSN is listed following the NR Gap Ack Block list. 332 Reserved : 16 bits 334 Currently not used. It is recommended a sender set all bits to zero 335 on transmit, and a receiver ignore this field. 337 Gap Ack Blocks: [Same as SACK chunk] 339 The NR-SACK contains zero or more Gap Ack Blocks. The Gap Ack Blocks 340 in an NR-SACK have the same semantics as in the existing SACK chunk. 341 Each Gap Ack Block acknowledges a subsequence of TSNs received 342 following a break in the sequence of received TSNs. By definition, 343 all TSNs acknowledged by Gap Ack Blocks are greater than the value of 344 the Cumulative TSN Ack. 346 Gap Ack Blocks are repeated for each Gap Ack Block up to 'N' defined 347 in the Number of Gap Ack Blocks field. All DATA chunks with TSNs 348 greater than or equal to (Cumulative TSN Ack + Gap Ack Block Start) 349 and less than or equal to (Cumulative TSN Ack + Gap Ack Block End) of 350 each Gap Ack Block are assumed to have been received correctly. 352 Gap Ack Block Start: 16 bits (unsigned integer) [Same as SACK chunk] 354 Indicates the Start offset TSN for this Gap Ack Block. This number 355 is set relative to the cumulative TSN number defined in Cumulative 356 TSN Ack field. To calculate the actual start TSN number, the 357 Cumulative TSN Ack is added to this offset number. The calculated 358 TSN identifies the first TSN in this Gap Ack Block that has been 359 received. 361 Gap Ack Block End: 16 bits (unsigned integer) [Same as SACK chunk] 363 Indicates the End offset TSN for this Gap Ack Block. This number is 364 set relative to the cumulative TSN number defined in the Cumulative 365 TSN Ack field. To calculate the actual TSN number, the Cumulative 366 TSN Ack is added to this offset number. The calculated TSN 367 identifies the TSN of the last DATA chunk received in this Gap Ack 368 Block. 370 N(on)R(enegable) Gap Ack Blocks: 372 The NR-SACK contains zero or more NR Gap Ack Blocks. Each NR Gap Ack 373 Block acknowledges a continuous subsequence of non-renegable out-of- 374 order DATA chunks. Each sequence of TSNs in an NR Gap Ack Block MUST 375 be a subsequence of one of the Gap Ack Blocks except for the special 376 case when 'A' bit is set to 1 (for example, see CASE-3 in Section 5.) 377 Note that there can be more than one NR Gap Ack Block per Gap Ack 378 Block. If a TSN is nr-gap-acked in any NR-SACK chunk, then all 379 subsequent NR-SACKs gap-acking that TSN SHOULD also nr-gap-ack that 380 TSN. 382 NR Gap Ack Blocks are repeated for each NR Gap Ack Block up to 'M' 383 defined in the Number of NR Gap Ack Blocks field. All DATA chunks 384 with TSNs greater than or equal to (Cumulative TSN Ack + NR Gap Ack 385 Block Start) and less than or equal to (Cumulative TSN Ack + NR Gap 386 Ack Block End) of each NR Gap Ack Block are assumed to be Non- 387 Renegable. 389 NR Gap Ack Block Start: 16 bits (unsigned integer) 391 Indicates the Start offset TSN for this NR Gap Ack Block. This 392 number is set relative to the cumulative TSN number defined in 393 Cumulative TSN Ack field. To calculate the actual TSN number, the 394 Cumulative TSN Ack is added to this offset number. The calculated 395 TSN identifies the first TSN in this NR Gap Ack Block that has been 396 received. 398 NR Gap Ack Block End: 16 bits (unsigned integer) 400 Indicates the End offset TSN for this NR Gap Ack Block. This number 401 is set relative to the cumulative TSN number defined in Cumulative 402 TSN Ack field. To calculate the actual TSN number, the Cumulative 403 TSN Ack is added to this offset number. The calculated TSN 404 identifies the TSN of the last DATA chunk received in this NR Gap Ack 405 Block. 407 Duplicate TSN: 32 bits (unsigned integer) [Same as SACK chunk] 409 Contain the TSNs received in duplicate since the last NR-SACK was 410 sent. They are repeated for each duplicate TSN up to 'X' defined in 411 Number of Duplicate TSNs field. 413 Each duplicate TSN is listed in this field as many times as the TSN 414 was received since the previous NR-SACK was sent. 416 For example, if a receiver were to get the TSN 19 three times, the 417 receiver would list 19 twice in the outbound NR-SACK. After sending 418 the NR-SACK if the receiver received yet one more TSN 19, the 419 receiver would list 19 as a duplicate once in the next outgoing NR- 420 SACK. 422 5. An Illustrative Example 424 Assume the following DATA chunks have arrived at the receiver. 426 -------------------------------- 427 | TSN=16| SID=2 | SSN=N/A| U=1 | 428 -------------------------------- 429 | TSN=15| SID=1 | SSN= 4 | U=0 | 430 -------------------------------- 431 | TSN=14| SID=0 | SSN= 4 | U=0 | 432 -------------------------------- 433 | TSN=13| SID=2 | SSN=N/A| U=1 | 434 -------------------------------- 435 | | 436 -------------------------------- 437 | TSN=11| SID=0 | SSN= 3 | U=0 | 438 ------------------------------- 439 | | 440 -------------------------------- 441 | | 442 -------------------------------- 443 | TSN=8 | SID=2 | SSN=N/A| U=1 | 444 -------------------------------- 445 | TSN=7 | SID=1 | SSN= 2 | U=0 | 446 -------------------------------- 447 | TSN=6 | SID=1 | SSN= 1 | U=0 | 448 -------------------------------- 449 | TSN=5 | SID=0 | SSN= 1 | U=0 | 450 -------------------------------- 451 | | 452 -------------------------------- 453 | TSN=3 | SID=1 | SSN= 0 | U=0 | 454 -------------------------------- 455 | TSN=2 | SID=0 | SSN= 0 | U=0 | 456 -------------------------------- 458 The above figure shows the list of DATA chunks at the receiver. TSN 459 denotes the transmission sequence number of the DATA chunk, SID 460 denotes the SCTP stream id to which the DATA chunk belongs, SSN 461 denotes the sequence number of the DATA chunk within its stream, and 462 U bit denotes whether the DATA chunk requires ordered or unordered 463 delivery [RFC4960]. 465 This data can be viewed as three separate streams as follows (assume 466 each stream begins with SSN=0.) Note that in this example, the 467 application uses stream 2 for unordered data transfer. By 468 definition, SSN fields of unordered DATA chunks are ignored. 470 Stream-0: 472 SSN: 0 1 2 3 4 473 TSN: | 2 | 5 | | 11 | 14 | 474 U-Bit: | 0 | 0 | | 0 | 0 | 476 Stream-1: 478 SSN: 0 1 2 3 4 479 TSN: | 3 | 6 | 7 | | 15 | 480 U-Bit: | 0 | 0 | 0 | | 0 | 482 Stream-2: 484 SSN: N/A N/A N/A 485 TSN: | 8 | 13 | 16 | 486 U-Bit: | 1 | 1 | 1 | 488 The NR-SACK to acknowledge the above data MUST be constructed as 489 follows for each of the three cases described below (the a_rwnd is 490 arbitrarily set to 4000): 492 CASE-1: Minimal Data Receiver Responsibility - no out-of-order 493 deliverable data yet delivered 495 None of the deliverable out-of-order DATA chunks have been delivered 496 and the receiver of the above data does not take responsibility for 497 any of the received out-of-order DATA chunks. The receiver reserves 498 the right to renege on any or all of the out-of-order DATA chunks. 500 +-----------------------------+-----------------------------+ 501 | Type = 0x10 | 0000000|A=0| Chunk Length = 32 | 502 +-----------------------------+-----------------------------+ 503 | Cumulative TSN Ack = 3 | 504 +-----------------------------+-----------------------------+ 505 | a_rwnd = 4000 | 506 +-----------------------------+-----------------------------+ 507 | Num of Gap Ack Blocks = 3 |Num of NR Gap Ack Blocks = 0 | 508 +-----------------------------+-----------------------------+ 509 | Num of Duplicates = 0 | 0x00 | 510 +-----------------------------+-----------------------------+ 511 | Gap Ack Block #1 Start = 2 | Gap Ack Block #1 End = 5 | 512 +-----------------------------+-----------------------------+ 513 | Gap Ack Block #2 Start = 8 | Gap Ack Block #2 End = 8 | 514 +-----------------------------+-----------------------------+ 515 | Gap Ack Block #3 Start = 10 | Gap Ack Block #3 End = 13 | 516 +-----------------------------+-----------------------------+ 518 CASE-2: Minimal Data Receiver Responsibility - all out-of-order 519 deliverable data delivered 521 In this case, the NR-SACK chunk is being sent after the data receiver 522 has delivered all deliverable out-of-order DATA chunks to its 523 receiving application. The receiver reserves the right to renege on 524 all undelivered out-of-order DATA chunks. 526 +------------------------------+------------------------------+ 527 | Type = 0x10 | 0000000|A=0 | Chunk Length = 44 | 528 +------------------------------+------------------------------+ 529 | Cumulative TSN Ack = 3 | 530 +------------------------------+------------------------------+ 531 | a_rwnd = 4000 | 532 +------------------------------+------------------------------+ 533 | Num of Gap Ack Block = 3 | Num of NR Gap Ack Block = 3 | 534 +------------------------------+------------------------------+ 535 | Num of Duplicates = 0 | 0x00 | 536 +------------------------------+------------------------------+ 537 | Gap Ack Block #1 Start = 2 | Gap Ack Block #1 End = 5 | 538 +------------------------------+------------------------------+ 539 | Gap Ack Block #2 Start = 8 | Gap Ack Block #2 End = 8 | 540 +------------------------------+------------------------------+ 541 | Gap Ack Block #3 Start = 10 | Gap Ack Block #3 End = 13 | 542 +------------------------------+------------------------------+ 543 |NR Gap Ack Block #1 Start = 2 | NR Gap Ack Block #1 End = 5 | 544 +------------------------------+------------------------------+ 545 |NR Gap Ack Block #2 Start = 10| NR Gap Ack Block #2 End = 10 | 546 +------------------------------+------------------------------+ 547 |NR Gap Ack Block #3 Start = 13| NR Gap Ack Block #3 End = 13 | 548 +------------------------------+------------------------------+ 550 CASE-3: Maximal Data Receiver Responsibility 552 In this special case, all out-of-order data blocks acknowledged are 553 non-renegable. This case would occur when the data receiver is 554 programmed never to renege, and takes responsibility to deliver all 555 DATA chunks that arrive out-of-order. In this case the (A)ll bit is 556 set to '1' indicating all out-of-order data blocks are nr-gap-acked. 557 Only when A = 1 is a sequence of TSNs in an NR Gap Ack Block not a 558 subsequence of one of the Gap Ack Blocks. 560 +--------------------------------+-------------------------------+ 561 | Type = 0x10 | 0000000|A=1| Chunk Length = 32 | 562 +--------------------------------+-------------------------------+ 563 | Cumulative TSN Ack = 3 | 564 +--------------------------------+-------------------------------+ 565 | a_rwnd = 4000 | 566 +--------------------------------+-------------------------------+ 567 | Num of Gap Ack Blocks = 0 | Num of NR Gap Ack Blocks = 3 | 568 +--------------------------------+-------------------------------+ 569 | Num of Duplicates = 0 | 0x00 | 570 +--------------------------------+-------------------------------+ 571 | NR Gap Ack Block #1 Start = 2 | NR Gap Ack Block #1 End = 5 | 572 +--------------------------------+-------------------------------+ 573 | NR Gap Ack Block #2 Start = 8 | NR Gap Ack Block #2 End = 8 | 574 +--------------------------------+-------------------------------+ 575 | NR Gap Ack Block #3 Start = 10 | NR Gap Ack Block #3 End = 13 | 576 +--------------------------------+-------------------------------+ 578 6. Procedures 580 The procedures regarding when to send an NR-SACK chunk are identical 581 to the procedures regarding when to send a SACK chunk, as outlined in 582 Section 6.2 of [RFC4960]. 584 6.1. Sending an NR-SACK chunk 586 All of the NR-SACK chunk fields identical to the SACK chunk MUST be 587 formed as described in Section 6.2 of [RFC4960]. 589 It is up to the data receiver whether or not to take responsibility 590 for delivery of each out-of-order DATA chunk. An out-of-order DATA 591 chunk that has already been delivered, or that the receiver takes 592 responsibility to deliver (i.e., guarantees not to renege) is Non 593 Renegable(NR), and SHOULD be included in an NR Gap Ack Block field of 594 the outgoing NR-SACK. 596 Consider three cases: 598 CASE-1: Data receiver takes no responsibility for delivery of any 599 out-of-order DATA chunks 601 CASE-2: Data receiver takes responsibility for all out-of-order DATA 602 chunks that are "deliverable" (i.e., DATA chunks in-sequence 603 within the stream they belong to, or DATA chunks whose (U)nordered 604 bit is set to '1') 606 CASE-3: Data receiver takes responsibility for delivery of all out- 607 of-order DATA chunks, whether deliverable or not deliverable 609 The data receiver SHOULD follow the procedures outlined below for 610 building the NR-SACK. 612 CASE-1: 614 1A) Identify the TSNs received out-of-order. 616 1B) For these out-of-order TSNs, identify the Gap Ack Blocks. Fill 617 the Number of Gap Ack Blocks (N) field, Gap Ack Block #i Start, 618 and Gap Ack Block #i End where i goes from 1 to N. 620 1C) Set the (A)ll bit to '0'. 622 1D) Set the Number of NR Gap Acks (M) field to '0'. 624 CASE-2: 626 2A) Identify the TSNs received out-of-order. 628 2B) For these out-of-order TSNs, identify the Gap Ack Blocks. Fill 629 the Number of Gap Ack Blocks (N) field, Gap Ack Block #i Start, 630 and Gap Ack Block #i End where i goes from 1 to N. 632 2C) For the received out-of-order TSNs, check the (U)nordered bit of 633 each TSN. Tag unordered TSNs as NR. 635 2D) For each stream, identify the TSNs which are out-of-order 636 relative to the association's entire flow of data, but in-sequence 637 within that stream. Tag those in-sequence TSNs as NR. 639 2E) For those TSNs tagged as NR, identify the NR Blocks. Fill the 640 Number of NR Gap Ack Blocks(M) field, NR Gap Ack Block #i Start, 641 and NR Gap Ack Block #i End where i goes from 1 to M. 643 CASE-3: 645 3A) Identify the TSNs received out-of-order. All of these TSNs 646 SHOULD be nr-gap-acked. 648 3B) For these out-of-order TSNs, identify the NR Gap Ack Blocks. 649 According to that information, fill the Number of NR Gap Ack 650 Blocks (M) field, NR Gap Ack Block #i Start, and NR Gap Ack Block 651 #i End where i goes from 1 to M. 653 3C) Set the (A)ll bit to '1'. 655 3D) Set the Number of Gap Acks (N) field to '0'. 657 6.2. Receiving an NR-SACK Chunk 659 When an NR-SACK chunk is received, all of the NR-SACK fields 660 identical to a SACK chunk SHOULD be processed and handled as in SACK 661 chunk handling outlined in Section 6.2.1 of [RFC4960]. 663 The NR Gap Ack Block Start(s) and NR Gap Ack Block End(s) are offsets 664 relative to the cum-ack. To calculate the actual range of nr-gap- 665 acked TSNs, the cum-ack MUST be added to the Start and End. 667 For example, assume an incoming NR-SACK chunk's cum-ack is 12 and an 668 NR Gap Ack Block defines the NR Gap Ack Block Start=5, and the NR Gap 669 Ack Block End=7. This NR Gap Ack block nr-gap-acks TSNs 17 through 670 19(inclusive.) 672 Upon reception of an NR-SACK chunk, all TSNs falling within an NR-Gap 673 Ack Block SHOULD be removed from the data sender's retransmission 674 queue as their delivery to the receiving application has either 675 already occurred, or is guaranteed by the data receiver. 677 Most of NR-SACK processing at the data sender can be implemented by 678 using the same routines as in SACK that process cum ack and gap ack, 679 followed by removal of nr-gap-acked DATA chunks from the 680 retransmission queue. However, with NR-SACKs, as out-of-order DATA 681 chunks also can be removed from the retranmission queue, gap ack 682 processing routine cannot rely on the contents of the data sender's 683 retransmission queue for correct processing. For example, while 684 calculating missing reports,the gap ack processing routine cannot 685 assume that the highest TSN transmitted is always at the tail (right 686 edge) of the retransmission queue. 688 7. Security Considerations 690 There are no security considerations addressed by this memo. 692 8. IANA considerations 694 This document defines a new chunk type to transfer the NR-SACK 695 information. Table 2 illustrates the new chunk type. 697 The new chunk type must come from the range of chunk types where the 698 upper two bits are zero. We recommend 0x10 but any other available 699 code point with the upper two bits set to zero is acceptable. 701 Chunk Type Chunk Name 702 -------------------------------------------------------------- 703 0x10 Non-Renegable Selective Acknowledgment (NR-SACK) 705 Table 2: NR-SACK Chunk 707 9. Acknowledgments 709 This Internet Draft is the result of a great deal of constructive 710 discussion with several people, notably Phillip Conrad, Nasif Ekiz, 711 and Jonathan Leighton. 713 10. References 715 10.1. Normative References 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", BCP 14, RFC 2119, March 1997. 720 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 721 Kozuka, "Stream Control Transmission Protocol (SCTP) 722 Dynamic Address Reconfiguration", RFC 5061, 723 September 2007. 725 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 726 RFC 4960, September 2007. 728 10.2. Informative References 730 [Natarajan] 731 Natarajan, P., Ekiz, N., Yilmaz, E., Amer, P., Iyengar, 732 J., and R. Stewart, "Performance of Non-Renegable 733 Selective Acknowledgments (NR-SACKs) for SCTP", Technical 734 Report 2008/344, Computer and Information Sciences Dept., 735 University of Delaware , (in progress). 737 Authors' Addresses 739 Preethi Natarajan 740 University of Delaware 741 Computer and Information Sciences Department 742 Newark, DE 19716 743 USA 745 Phone: 746 Email: nataraja@cis.udel.edu 748 Paul D. Amer 749 University of Delaware 750 Computer and Information Sciences Department 751 Newark, DE 19716 752 USA 754 Phone: 755 Email: amer@cis.udel.edu 757 Ertugrul Yilmaz 758 University of Delaware 759 Computer and Information Sciences Department 760 Newark, DE 19716 761 USA 763 Phone: 764 Email: eyilmaz@cis.udel.edu 766 Randall R. Stewart 767 Cisco Systems, Inc. 768 4875 Forest Drive 769 Suite 200 770 Columbia, SC 29206 771 USA 773 Phone: 774 Email: rrs@cisco.com 775 Janardhan Iyengar 776 Connecticut College 777 Computer Science Department 778 270 Mohegan Avenue 779 New London, CT 06320-4196 780 USA 782 Phone: 860-439-5048 783 Email: iyengar@conncoll.edu 785 Full Copyright Statement 787 Copyright (C) The IETF Trust (2008). 789 This document is subject to the rights, licenses and restrictions 790 contained in BCP 78, and except as set forth therein, the authors 791 retain all their rights. 793 This document and the information contained herein are provided on an 794 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 795 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 796 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 797 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 798 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 799 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 801 Intellectual Property 803 The IETF takes no position regarding the validity or scope of any 804 Intellectual Property Rights or other rights that might be claimed to 805 pertain to the implementation or use of the technology described in 806 this document or the extent to which any license under such rights 807 might or might not be available; nor does it represent that it has 808 made any independent effort to identify any such rights. Information 809 on the procedures with respect to rights in RFC documents can be 810 found in BCP 78 and BCP 79. 812 Copies of IPR disclosures made to the IETF Secretariat and any 813 assurances of licenses to be made available, or the result of an 814 attempt made to obtain a general license or permission for the use of 815 such proprietary rights by implementers or users of this 816 specification can be obtained from the IETF on-line IPR repository at 817 http://www.ietf.org/ipr. 819 The IETF invites any interested party to bring to its attention any 820 copyrights, patents or patent applications, or other proprietary 821 rights that may cover technology that may be required to implement 822 this standard. Please address the information to the IETF at 823 ietf-ipr@ietf.org. 825 Acknowledgment 827 Funding for the RFC Editor function is provided by the IETF 828 Administrative Support Activity (IASA).