idnits 2.17.1 draft-natarajan-tsvwg-sctp-nrsack-06.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 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 and authors 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 (August 18, 2010) is 4993 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Ekiz 3 Internet-Draft P. Amer 4 Intended status: Standards Track University of Delaware 5 Expires: February 19, 2011 P. Natarajan 6 Cisco Systems 7 R. Stewart 8 Researcher 9 J. Iyengar 10 Franklin & Marshall College 11 August 18, 2010 13 Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP 14 draft-natarajan-tsvwg-sctp-nrsack-06.txt 16 Abstract 18 Stream Control Transmission Protocol (SCTP) [RFC4960] specifies 19 Selective Acknowledgements (SACKs) to allow an SCTP data receiver to 20 acknowledge DATA chunks which arrive out-of-order. In SCTP, SACK 21 information is advisory -- though SACKs notify a data sender about 22 the reception of specific out-of-order data, the SCTP data receiver 23 is permitted to later discard the data, a.k.a reneging. Since 24 delivery of a SACKed out-of-order DATA chunk is not guaranteed, a 25 copy of this DATA chunk MUST be kept in the data sender's 26 retransmission queue until this DATA chunk is cumulatively acked. 28 By definition, data that has been delivered to the application is 29 non-renegable by the SCTP data receiver. (Recall that, in SCTP, out- 30 of-order data can sometimes be delivered.) Also, SCTP 31 implementations can be configured such that the SCTP data receiver is 32 not allowed to, and therefore, never reneges on out-of-order data. 33 With SCTP's current SACK mechanism, non-renegable out-of-order data 34 is selectively acked, and is (wrongly) deemed renegable by the SCTP 35 data sender. 37 This document specifies an extension to SCTP's acknowledgment 38 mechanism called Non-Renegable Selective Acknowledgements (NR-SACKs.) 39 NR-SACKs enable a data receiver to explicitly inform the data sender 40 of non-renegable out-of-order data. As opposed to renegable data, a 41 data sender can consider non-renegable data as never requiring 42 retransmission, and therefore can remove non-renegable data from the 43 retransmission queue. 45 Status of this Memo 47 This Internet-Draft is submitted to IETF in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at http://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on February 19, 2011. 62 Copyright Notice 64 Copyright (c) 2010 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 4. The New Chunk Type: Non-Renegable SACK (NR-SACK) . . . . . . . 6 83 5. An Illustrative Example . . . . . . . . . . . . . . . . . . . 11 84 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 6.1. Sending an NR-SACK chunk . . . . . . . . . . . . . . . . . 14 86 6.2. Receiving an NR-SACK Chunk . . . . . . . . . . . . . . . . 16 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 88 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 95 1. Introduction 97 In providing end-to-end reliable data transfer, SCTP specifies 98 Cumulative Acknowledgements (ACKs), Selective ACKs (SACKs), and 99 Duplicate Selective ACKs (D-SACKs). These three types of acks are 100 carried in the following fields of the SACK chunk, respectively: 101 Cumulative TSN Ack, Gap Ack Block, and Duplicate TSN. In this 102 document, we refer to the Cumulative TSN Ack as the "cum-ack", the 103 selective Gap Ack Blocks as "gap-acks", and the Duplicate TSN 104 selective acks as "dup-TSN reports". 106 Gap-acks acknowledge DATA chunks that arrive out-of-order to a 107 transport layer data receiver. A gap-ack in SCTP is advisory, in 108 that, while it notifies a data sender about the reception of 109 indicated DATA chunks, the data receiver is permitted to later 110 discard DATA chunks that it previously had gap-acked. Discarding a 111 previously gap-acked DATA chunk is known as "reneging." Because of 112 the possibility of reneging in SCTP, any gap-acked DATA chunk MUST 113 NOT be removed from the data sender's retransmission queue until the 114 DATA chunk is later cum-acked. 116 Situations exist when a data receiver knows that reneging on a 117 particular out-of-order DATA chunk will never take place, such as 118 (but not limited to) after an out-of-order DATA chunk is delivered to 119 the receiving application. This document describes an extension to 120 SCTP to allow for Non-Renegable Selective Acknowledgments (NR-SACKs). 121 A new NR-SACK chunk type is described that allows this extension to 122 be implemented. 124 The NR-SACK chunk is an extension of the existing SACK chunk. 125 Several fields are identical, including the Cumulative TSN Ack, the 126 Advertised Receiver Window Credit (a_rwnd), and Duplicate TSNs. 127 These fields have the same semantics as described in [RFC4960]. 129 NR-SACKs extend SACKs by also identifying out-of-order DATA chunks 130 that a receiver either: (1) has delivered to its receiving 131 application, or (2) takes full responsibility to eventually deliver 132 to its receiving application. These out-of-order DATA chunks are 133 "non-renegable." Non-Renegable data are reported in the NR Gap Ack 134 Block field of the NR-SACK chunk as described in Section 4.1. We 135 refer to non-renegable selective acknowledgements as "nr-gap-acks." 137 When an out-of-order DATA chunk is nr-gap-acked, the data sender no 138 longer needs to keep that particular DATA chunk in its retransmission 139 queue, thus allowing the data sender to free up its buffer space 140 sooner than if the DATA chunk were only gap-acked. NR-SACKs have 141 been shown to better utilize the data sender's memory and improve 142 throughput, at the trade-off of generating and processing additional 143 acknowledgement information [Natarajan], [Yilmaz]. 145 An SCTP message is encapsulated within a single DATA chunk or within 146 multiple DATA chunks in case of fragmentation. In this document 147 without loss of generality, each application message maps to a single 148 transport layer DATA chunk, and delivering a DATA chunk to a 149 receiving application means delivering the message carried within the 150 DATA chunk to a receiving application. 152 SCTP divides an end-to-end association into independent logical data 153 streams (a.k.a. multistreaming.) A DATA chunk that arrives in- 154 sequence within a stream can be delivered to the receiving 155 application even if the DATA chunk is out-of-order relative to the 156 association's overall flow of data. These out-of-order DATA chunks 157 are "deliverable." By definition, a DATA chunk marked for unordered 158 delivery also is "deliverable" to the receiving application 159 immediately upon reception, regardless of its position within the 160 overall flow of data. 162 With current SACKs in SCTP, it is not possible for a data receiver to 163 inform a data sender if or when a particular out-of-order 164 "deliverable" DATA chunk has been "delivered" to the receiving 165 application. Thus the data sender MUST keep a copy of every gap- 166 acked out-of-order DATA chunk(s) in the data sender's retransmission 167 queue until the DATA chunk is cum-acked. This use of the data 168 sender's retransmission queue is wasteful. Given the receiving 169 application has received the data, the data sender has no reason to 170 keep this data in its retransmission queue. Yet, the sending 171 transport layer keeps the data because no mechanism currently exists 172 to indicate which out-of-order DATA chunks have been delivered. 173 (Note: once a DATA chunk is delivered to the receiving application, 174 it is impossible for the data receiver to renege on that DATA chunk.) 176 If NR-SACKs are used, the data receiver MAY include the TSN of a 177 delivered out-of-order DATA chunk in an NR-SACK to inform the data 178 sender that the delivery has occurred, allowing the data sender to 179 remove the copy of the delivered DATA chunk from the data sender's 180 retransmission queue even before the DATA chunk is cum-acked. 182 2. Conventions 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 3. Negotiation 190 Before sending/receiving NR-SACKs, both peer endpoints MUST agree on 191 using NR-SACKs. This agreement MUST be negotiated during association 192 establishment. NR-SACK is an extension to the core SCTP, and SCTP 193 extensions that an endpoint supports are reported to the peer 194 endpoint in Supported Extensions Parameter during association 195 establishment (see Section 4.2.7 of [RFC5061].) The Supported 196 Extensions Parameter consists of a list of non-standard Chunk Types 197 that are supported by the sender. 199 An endpoint supporting the NR-SACK extension MUST list the NR-SACK 200 chunk in the Supported Extensions Parameter carried in the INIT or 201 INIT-ACK chunk, depending on whether the endpoint initiates or 202 responds to the initiation of the association. If the NR-SACK chunk 203 type ID is listed in the Chunk Types List of the Supported Extensions 204 Parameter, then the receiving endpoint MUST assume that the NR-SACK 205 chunk is supported by the sending endpoint. 207 Both endpoints MUST support NR-SACKs for either endpoint to send an 208 NR-SACK. If an endpoint establishes an association with a remote 209 endpoint that does not list NR-SACK in the Supported Extensions 210 Parameter carried in INIT chunk, then both endpoints of the 211 association MUST NOT use NR-SACKs. After association establishment, 212 an endpoint MUST NOT renegotiate the use of NR-SACKs. 214 Once both endpoints indicate during association establishment that 215 they support the NR-SACK extension, each endpoint SHOULD acknowledge 216 received DATA chunks with NR-SACK chunks, and not SACK chunks. That 217 is, throughout an SCTP association, both endpoints SHOULD send either 218 SACK chunks or NR-SACK chunks, never a mixture of the two. 220 4. The New Chunk Type: Non-Renegable SACK (NR-SACK) 222 Table 1 illustrates a new chunk type that will be used to transfer 223 NR-SACK information. 225 Chunk Type Chunk Name 226 -------------------------------------------------------------- 227 0x10 Non-Renegable Selective Acknowledgment (NR-SACK) 229 Table 1: NR-SACK Chunk 231 As the NR-SACK chunk replaces the SACK chunk, many SACK chunk fields 232 are preserved in the NR-SACK chunk. These preserved fields have the 233 same semantics with the corresponding SACK chunk fields, as defined 234 in [RFC4960], Section 3.3.4. The Gap Ack fields from RFC4960 have 235 been renamed as R Gap Ack to emphasize their renegable nature. Their 236 semantics are unchanged. For completeness, we describe all fields of 237 the NR-SACK chunk, including those that are identical in the SACK 238 chunk. 240 Similar to the SACK chunk, the NR-SACK chunk is sent to a peer 241 endpoint to (1) acknowledge DATA chunks received in-order, (2) 242 acknowledge DATA chunks received out-of-order, and (3) identify DATA 243 chunks received more than once (i.e., duplicate.) In addition, the 244 NR-SACK chunk (4) informs the peer endpoint of non-renegable out-of- 245 order DATA chunks. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type = 0x10 | Chunk Flags | Chunk Length | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Cumulative TSN Ack | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Advertised Receiver Window Credit (a_rwnd) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |Number of R Gap Ack Blocks = N |Number of NR Gap Ack Blocks = M| 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Number of Duplicate TSNs = X | Reserved | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | R Gap Ack Block #1 Start | R Gap Ack Block #1 End | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 / / 263 \ ... \ 264 / / 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | R Gap Ack Block #N Start | R Gap Ack Block #N End | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | NR Gap Ack Block #1 Start | NR Gap Ack Block #1 End | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 / / 271 \ ... \ 272 / / 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | NR Gap Ack Block #M Start | NR Gap Ack Block #M End | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Duplicate TSN 1 | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 / / 279 \ ... \ 280 / / 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Duplicate TSN X | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Type: 8 bits 287 This field holds the IANA defined chunk type for NR-SACK chunk. The 288 suggested value of this field for IANA is 0x10. 290 Chunk Flags: 8 bits 292 Currently not used. It is recommended a sender set all bits to zero 293 on transmit, and a receiver ignore this field. 295 Chunk Length: 16 bits (unsigned integer) [Same as SACK chunk] 297 This value represents the size of the chunk in bytes including the 298 Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. 300 Cumulative TSN Ack: 32 bits (unsigned integer) [Same as SACK chunk] 302 The value of the Cumulative TSN Ack is the last TSN received before a 303 break in the sequence of received TSNs occurs. The next TSN value 304 following the Cumulative TSN Ack has not yet been received at the 305 endpoint sending the NR-SACK. 307 Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned 308 integer) [Same as SACK chunk] 310 Indicates the updated receive buffer space in bytes of the sender of 311 this NR-SACK, see Section 6.2.1 of [RFC4960] for details. 313 Number of (R)enegable Gap Ack Blocks (N): 16 bits (unsigned integer) 315 Indicates the number of Renegable Gap Ack Blocks included in this NR- 316 SACK. 318 Number of (N)on(R)enegable Gap Ack Blocks (M): 16 bits (unsigned 319 integer) 321 Indicates the number of Non-Renegable Gap Ack Blocks included in this 322 NR-SACK. 324 Number of Duplicate TSNs (X): 16 bits [Same as SACK chunk] 326 Contains the number of duplicate TSNs the endpoint has received. 327 Each duplicate TSN is listed following the NR Gap Ack Block list. 329 Reserved : 16 bits 330 Currently not used. It is recommended a sender set all bits to zero 331 on transmit, and a receiver ignore this field. 333 (R)enegable Gap Ack Blocks: 335 The NR-SACK contains zero or more R Gap Ack Blocks. Each R Gap Ack 336 Block acknowledges a subsequence of renegable out-of-order TSNs. By 337 definition, all TSNs acknowledged by R Gap Ack Blocks are "greater 338 than" the value of the Cumulative TSN Ack. 340 Because of TSN numbering wraparound, comparisons and all arithmetic 341 operations discussed in this document are based on "Serial Number 342 Arithmetic" as described in Section 1.6 of [RFC4960]. 344 R Gap Ack Blocks are repeated for each R Gap Ack Block up to 'N' 345 defined in the Number of R Gap Ack Blocks field. All DATA chunks 346 with TSNs >= (Cumulative TSN Ack + R Gap Ack Block Start) and <= 347 (Cumulative TSN Ack + R Gap Ack Block End) of each R Gap Ack Block 348 are assumed to have been received correctly, and are renegable. 350 R Gap Ack Block Start: 16 bits (unsigned integer) 352 Indicates the Start offset TSN for this R Gap Ack Block. This number 353 is set relative to the cumulative TSN number defined in Cumulative 354 TSN Ack field. To calculate the actual start TSN number, the 355 Cumulative TSN Ack is added to this offset number. The calculated 356 TSN identifies the first TSN in this R Gap Ack Block that has been 357 received. 359 R Gap Ack Block End: 16 bits (unsigned integer) 361 Indicates the End offset TSN for this R Gap Ack Block. This number 362 is set relative to the cumulative TSN number defined in the 363 Cumulative TSN Ack field. To calculate the actual TSN number, the 364 Cumulative TSN Ack is added to this offset number. The calculated 365 TSN identifies the TSN of the last DATA chunk received in this R Gap 366 Ack Block. 368 N(on)R(enegable) Gap Ack Blocks: 370 The NR-SACK contains zero or more NR Gap Ack Blocks. Each NR Gap Ack 371 Block acknowledges a continuous subsequence of non-renegable out-of- 372 order DATA chunks. If a TSN is nr-gap-acked in any NR-SACK chunk, 373 then all subsequently transmitted NR-SACKs with a smaller cum-ack 374 value than that TSN SHOULD also nr-gap-ack that TSN. 376 NR Gap Ack Blocks are repeated for each NR Gap Ack Block up to 'M' 377 defined in the Number of NR Gap Ack Blocks field. All DATA chunks 378 with TSNs >= (Cumulative TSN Ack + NR Gap Ack Block Start) and <= 379 (Cumulative TSN Ack + NR Gap Ack Block End) of each NR Gap Ack Block 380 are assumed to be received correctly, and are Non-Renegable. 382 NR Gap Ack Block Start: 16 bits (unsigned integer) 384 Indicates the Start offset TSN for this NR Gap Ack Block. This 385 number is set relative to the cumulative TSN number defined in 386 Cumulative TSN Ack field. To calculate the actual TSN number, the 387 Cumulative TSN Ack is added to this offset number. The calculated 388 TSN identifies the first TSN in this NR Gap Ack Block that has been 389 received. 391 NR Gap Ack Block End: 16 bits (unsigned integer) 393 Indicates the End offset TSN for this NR Gap Ack Block. This number 394 is set relative to the cumulative TSN number defined in Cumulative 395 TSN Ack field. To calculate the actual TSN number, the Cumulative 396 TSN Ack is added to this offset number. The calculated TSN 397 identifies the TSN of the last DATA chunk received in this NR Gap Ack 398 Block. 400 Note: 402 NR Gap Ack Blocks and R Gap Ack Blocks in an NR-SACK chunk SHOULD 403 acknowledge disjoint sets of TSNs. That is, an out-of-order TSN 404 SHOULD be listed in either an R Gap Ack Block or an NR Gap Ack Block, 405 but not the both. R Gap Ack Blocks and NR Gap Ack Blocks together 406 provide the information as do the Gap Ack Block of a SACK chunk, plus 407 additional information about non-renegability. 409 If all out-of-order data acked by an NR-SACK are renegable, then the 410 Number of NR Gap Ack Blocks MUST be set to 0. If all out-of-order 411 data acked by an NR-SACK are non-renegable, then the Number of R Gap 412 Ack Blocks SHOULD be set to 0. TSNs listed in R Gap Ack Block will 413 be referred as r-gap-acked. 415 Duplicate TSN: 32 bits (unsigned integer) [Same as SACK chunk] 417 Indicates a duplicate TSN received since the last NR-SACK was sent. 418 Exactly 'X' duplicate TSNs SHOULD be reported where 'X' was defined 419 in Number of Duplicate TSNs field. 421 Each duplicate TSN is listed in this field as many times as the TSN 422 was received since the previous NR-SACK was sent. For example, if a 423 data receiver were to get the TSN 19 three times, the data receiver 424 would list 19 twice in the outbound NR-SACK. After sending the NR- 425 SACK if the receiver received one more TSN 19, the receiver would 426 list 19 as a duplicate once in the next outgoing NR-SACK. 428 5. An Illustrative Example 430 Assume the following DATA chunks have arrived at the receiver. 432 -------------------------------- 433 | TSN=16| SID=2 | SSN=N/A| U=1 | 434 -------------------------------- 435 | TSN=15| SID=1 | SSN= 4 | U=0 | 436 -------------------------------- 437 | TSN=14| SID=0 | SSN= 4 | U=0 | 438 -------------------------------- 439 | TSN=13| SID=2 | SSN=N/A| U=1 | 440 -------------------------------- 441 | | 442 -------------------------------- 443 | TSN=11| SID=0 | SSN= 3 | U=0 | 444 ------------------------------- 445 | | 446 -------------------------------- 447 | | 448 -------------------------------- 449 | TSN=8 | SID=2 | SSN=N/A| U=1 | 450 -------------------------------- 451 | TSN=7 | SID=1 | SSN= 2 | U=0 | 452 -------------------------------- 453 | TSN=6 | SID=1 | SSN= 1 | U=0 | 454 -------------------------------- 455 | TSN=5 | SID=0 | SSN= 1 | U=0 | 456 -------------------------------- 457 | | 458 -------------------------------- 459 | TSN=3 | SID=1 | SSN= 0 | U=0 | 460 -------------------------------- 461 | TSN=2 | SID=0 | SSN= 0 | U=0 | 462 -------------------------------- 464 The above figure shows the list of DATA chunks at the receiver. TSN 465 denotes the transmission sequence number of the DATA chunk, SID 466 denotes the stream id to which the DATA chunk belongs, SSN denotes 467 the sequence number of the DATA chunk within its stream, and the U 468 bit denotes whether the DATA chunk requires ordered(=0) or 469 unordered(=1) delivery [RFC4960]. Note that TSNs 4,9,10, and 12 have 470 not arrived. 472 This data can be viewed as three separate streams as follows (assume 473 each stream begins with SSN=0.) Note that in this example, the 474 application uses stream 2 for unordered data transfer. By 475 definition, SSN fields of unordered DATA chunks are ignored. 477 Stream-0: 479 SSN: 0 1 2 3 4 480 TSN: | 2 | 5 | | 11 | 14 | 481 U-Bit: | 0 | 0 | | 0 | 0 | 483 Stream-1: 485 SSN: 0 1 2 3 4 486 TSN: | 3 | 6 | 7 | | 15 | 487 U-Bit: | 0 | 0 | 0 | | 0 | 489 Stream-2: 491 SSN: N/A N/A N/A 492 TSN: | 8 | 13 | 16 | 493 U-Bit: | 1 | 1 | 1 | 495 The NR-SACK to acknowledge the above data SHOULD be constructed as 496 follows for each of the three cases described below (the a_rwnd is 497 arbitrarily set to 4000): 499 CASE-1: Minimal Data Receiver Responsibility - no out-of-order 500 deliverable data yet delivered 502 None of the deliverable out-of-order DATA chunks have been delivered, 503 and the receiver of the above data does not take responsibility for 504 any of the received out-of-order DATA chunks. The receiver reserves 505 the right to renege any or all of the out-of-order DATA chunks. 507 +-----------------------------+-----------------------------+ 508 | Type = 0x10 | 00000000 | Chunk Length = 32 | 509 +-----------------------------+-----------------------------+ 510 | Cumulative TSN Ack = 3 | 511 +-----------------------------+-----------------------------+ 512 | a_rwnd = 4000 | 513 +-----------------------------+-----------------------------+ 514 | Num of R Gap Ack Blocks = 3 |Num of NR Gap Ack Blocks = 0 | 515 +-----------------------------+-----------------------------+ 516 | Num of Duplicates = 0 | 0x00 | 517 +-----------------------------+-----------------------------+ 518 |R Gap Ack Block #1 Start = 2 | R Gap Ack Block #1 End = 5 | 519 +-----------------------------+-----------------------------+ 520 |R Gap Ack Block #2 Start = 8 | R Gap Ack Block #2 End = 8 | 521 +-----------------------------+-----------------------------+ 522 |R Gap Ack Block #3 Start = 10| R Gap Ack Block #3 End = 13 | 523 +-----------------------------+-----------------------------+ 525 CASE-2: Minimal Data Receiver Responsibility - all out-of-order 526 deliverable data delivered 528 In this case, the NR-SACK chunk is being sent after the data receiver 529 has delivered all deliverable out-of-order DATA chunks to its 530 receiving application(i.e., TSNs 5,6,7,8,13, and 16.) The receiver 531 reserves the right to renege on all undelivered out-of-order DATA 532 chunks(i.e., TSNs 11,14, and 15.) 534 +------------------------------+------------------------------+ 535 | Type = 0x10 | 0x00 | Chunk Length = 40 | 536 +------------------------------+------------------------------+ 537 | Cumulative TSN Ack = 3 | 538 +------------------------------+------------------------------+ 539 | a_rwnd = 4000 | 540 +------------------------------+------------------------------+ 541 | Num of R Gap Ack Blocks = 2 | Num of NR Gap Ack Blocks = 3 | 542 +------------------------------+------------------------------+ 543 | Num of Duplicates = 0 | 0x00 | 544 +------------------------------+------------------------------+ 545 | R Gap Ack Block #1 Start = 8 | R Gap Ack Block #1 End = 8 | 546 +------------------------------+------------------------------+ 547 | R Gap Ack Block #2 Start = 11| R Gap Ack Block #2 End = 12 | 548 +------------------------------+------------------------------+ 549 |NR Gap Ack Block #1 Start = 2 | NR Gap Ack Block #1 End = 5 | 550 +------------------------------+------------------------------+ 551 |NR Gap Ack Block #2 Start = 10| NR Gap Ack Block #2 End = 10 | 552 +------------------------------+------------------------------+ 553 |NR Gap Ack Block #3 Start = 13| NR Gap Ack Block #3 End = 13 | 554 +------------------------------+------------------------------+ 556 CASE-3: Maximal Data Receiver Responsibility 558 In this special case, all out-of-order data blocks acknowledged are 559 non-renegable. This case would occur when the data receiver is 560 programmed never to renege, and takes responsibility to deliver all 561 DATA chunks that arrive out-of-order. In this case Num of R Gap Ack 562 Blocks is zero indicating all reported out-of-order TSNs are nr-gap- 563 acked. 565 +--------------------------------+-------------------------------+ 566 | Type = 0x10 | 0x00 | Chunk Length = 32 | 567 +--------------------------------+-------------------------------+ 568 | Cumulative TSN Ack = 3 | 569 +--------------------------------+-------------------------------+ 570 | a_rwnd = 4000 | 571 +--------------------------------+-------------------------------+ 572 | Num of R Gap Ack Blocks = 0 | Num of NR Gap Ack Blocks = 3 | 573 +--------------------------------+-------------------------------+ 574 | Num of Duplicates = 0 | 0x00 | 575 +--------------------------------+-------------------------------+ 576 | NR Gap Ack Block #1 Start = 2 | NR Gap Ack Block #1 End = 5 | 577 +--------------------------------+-------------------------------+ 578 | NR Gap Ack Block #2 Start = 8 | NR Gap Ack Block #2 End = 8 | 579 +--------------------------------+-------------------------------+ 580 | NR Gap Ack Block #3 Start = 10 | NR Gap Ack Block #3 End = 13 | 581 +--------------------------------+-------------------------------+ 583 6. Procedures 585 The procedures regarding "when" to send an NR-SACK chunk are 586 identical to the procedures regarding when to send a SACK chunk, as 587 outlined in Section 6.2 of [RFC4960]. 589 6.1. Sending an NR-SACK chunk 591 All of the NR-SACK chunk fields identical to the SACK chunk MUST be 592 formed as described in Section 6.2 of [RFC4960]. 594 It is up to the data receiver whether or not to take responsibility 595 for delivery of each out-of-order DATA chunk. An out-of-order DATA 596 chunk that has already been delivered, or that the receiver takes 597 responsibility to deliver (i.e., guarantees not to renege) is Non 598 Renegable(NR), and SHOULD be included in an NR Gap Ack Block field of 599 the outgoing NR-SACK. All other out-of-order data is (R)enegable, 600 and SHOULD be included in R Gap Ack Block field of the outgoing NR- 601 SACK. 603 Consider three types of data receiver: 605 CASE-1: Data receiver takes no responsibility for delivery of any 606 out-of-order DATA chunks 608 CASE-2: Data receiver takes responsibility for all out-of-order DATA 609 chunks that are "deliverable" (i.e., DATA chunks in-sequence 610 within the stream they belong to, or DATA chunks whose (U)nordered 611 bit is 1) 613 CASE-3: Data receiver takes responsibility for delivery of all out- 614 of-order DATA chunks, whether deliverable or not deliverable 616 The data receiver SHOULD follow the procedures outlined below for 617 building the NR-SACK. 619 CASE-1: 621 1A) Identify the TSNs received out-of-order. 623 1B) For these out-of-order TSNs, identify the R Gap Ack Blocks. 624 Fill the Number of R Gap Ack Blocks (N) field, R Gap Ack Block #i 625 Start, and R Gap Ack Block #i End where i goes from 1 to N. 627 1C) Set the Number of NR Gap Ack Blocks (M) field to 0. 629 CASE-2: 631 2A) Identify the TSNs received out-of-order. 633 2B) For the received out-of-order TSNs, check the (U)nordered bit of 634 each TSN. Tag unordered TSNs as NR. 636 2C) For each stream, also identify the TSNs received out-of-order 637 but are in-sequence within that stream. Tag those in-sequence 638 TSNs as NR. 640 2D) Tag all out-of-order data that is not NR as (R)enegable. 642 2E) For those TSNs tagged as (R)enegable, identify the (R)enegable 643 Blocks. Fill the Number of R Gap Ack Blocks(N) field, R Gap Ack 644 Block #i Start, and R Gap Ack Block #i End where i goes from 1 to 645 N. 647 2F) For those TSNs tagged as NR, identify the NR Blocks. Fill the 648 Number of NR Gap Ack Blocks(M) field, NR Gap Ack Block #i Start, 649 and NR Gap Ack Block #i End where i goes from 1 to M. 651 CASE-3: 653 3A) Identify the TSNs received out-of-order. All of these TSNs 654 SHOULD be nr-gap-acked. 656 3B) Set the Number of R Gap Ack Blocks (N) field to 0. 658 3C) For these out-of-order TSNs, identify the NR Gap Ack Blocks. 659 Fill the Number of NR Gap Ack Blocks (M) field, NR Gap Ack Block 660 #i Start, and NR Gap Ack Block #i End where i goes from 1 to M. 662 RFC4960 states that the SCTP endpoint MUST report as many Gap Ack 663 Blocks as can fit in a single SACK chunk limited by the current path 664 MTU. When using NR-SACKs, the SCTP endpoint SHOULD fill as many R 665 Gap Ack Blocks and NR Gap Ack Blocks starting from the Cumulative TSN 666 Ack value as can fit in a single NR-SACK chunk limited by the current 667 path MTU. If space remains, the SCTP endpoint SHOULD fill as many 668 Duplicate TSNs as possible starting from Cumulative TSN Ack value. 670 6.2. Receiving an NR-SACK Chunk 672 When an NR-SACK chunk is received, all of the NR-SACK fields 673 identical to a SACK chunk SHOULD be processed and handled as in SACK 674 chunk handling outlined in Section 6.2.1 of [RFC4960]. 676 The NR Gap Ack Block Start(s) and NR Gap Ack Block End(s) are offsets 677 relative to the cum-ack. To calculate the actual range of nr-gap- 678 acked TSNs, the cum-ack MUST be added to the Start and End. 680 For example, assume an incoming NR-SACK chunk's cum-ack is 12 and an 681 NR Gap Ack Block defines the NR Gap Ack Block Start=5, and the NR Gap 682 Ack Block End=7. This NR Gap Ack block nr-gap-acks TSNs 17 through 683 19 inclusive. 685 Upon reception of an NR-SACK chunk, all TSNs listed in either R Gap 686 Ack Block(s) or NR Gap Ack Block(s) SHOULD be processed as would be 687 TSNs included in Gap Ack Block(s) of a SACK chunk. All TSNs in all 688 NR Gap Ack Blocks SHOULD be removed from the data sender's 689 retransmission queue as their delivery to the receiving application 690 has either already occurred, or is guaranteed by the data receiver. 692 Although R Gap Ack Blocks and NR Gap Ack Blocks SHOULD be disjoint 693 sets, NR-SACK processing SHOULD work if an NR-SACK chunk has a TSN 694 listed in both an R Gap Ack Block and an NR Gap Ack Block. In this 695 case, the TSN SHOULD be treated as Non-Renegable. 697 Implementation Note: 699 Most of NR-SACK processing at the data sender can be implemented by 700 using the same routines as in SACK that process the cum ack and the 701 gap ack(s), followed by removal of nr-gap-acked DATA chunks from the 702 retransmission queue. However, with NR-SACKs, as out-of-order DATA 703 is sometimes removed from the retransmission queue, the gap ack 704 processing routine should recognize that the data sender's 705 retransmission queue has some transmitted data removed. For example, 706 while calculating missing reports, the gap ack processing routine 707 cannot assume that the highest TSN transmitted is always at the tail 708 (right edge) of the retransmission queue. 710 7. Security Considerations 712 This document does not add any security considerations to those 713 specified in [RFC4960]. 715 8. IANA considerations 717 This document defines a new chunk type to transfer the NR-SACK 718 information. Table 2 illustrates the new chunk type. 720 The new chunk type must come from the range of chunk types where the 721 upper two bits are zero. We recommend 0x10 but any other available 722 code point with the upper two bits set to zero is acceptable. 724 Chunk Type Chunk Name 725 -------------------------------------------------------------- 726 0x10 Non-Renegable Selective Acknowledgment (NR-SACK) 728 Table 2: NR-SACK Chunk 730 9. Acknowledgments 732 This Internet Draft is the result of a great deal of constructive 733 discussion with several people, notably Phillip Conrad, Ertugrul 734 Yilmaz, and Jonathan Leighton. 736 10. References 738 10.1. Normative References 740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 741 Requirement Levels", BCP 14, RFC 2119, March 1997. 743 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 744 Kozuka, "Stream Control Transmission Protocol (SCTP) 745 Dynamic Address Reconfiguration", RFC 5061, 746 September 2007. 748 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 749 RFC 4960, September 2007. 751 10.2. Informative References 753 [Natarajan] 754 Natarajan, P., Ekiz, N., Yilmaz, E., Amer, P., Iyengar, 755 J., and R. Stewart, "Non-Renegable Selective 756 Acknowledgments (NR-SACKs) for SCTP", International 757 Conference on Network Protocols (ICNP) 2008, Orlando, 758 October 2008 . 760 [Yilmaz] Yilmaz, E., Ekiz, N., Natarajan, P., Amer, P., Leighton, 761 J., Baker, F., and R. Stewart, "Throughput analysis of 762 Non-Renegable Selective Acknowledgments (NR-SACKs) for 763 SCTP", Comput. Commun. (2010), doi:10.1016/ 764 j.comcom.2010.06.028 . 766 Authors' Addresses 768 Nasif Ekiz 769 University of Delaware 770 Computer and Information Sciences Department 771 Newark, DE 19716 772 USA 774 Phone: 775 Email: nekiz@udel.edu 777 Paul D. Amer 778 University of Delaware 779 Computer and Information Sciences Department 780 Newark, DE 19716 781 USA 783 Phone: 302-831-1944 784 Email: amer@cis.udel.edu 786 Preethi Natarajan 787 Cisco Systems 788 170 West Tasman Drive 789 San Jose, CA 95134 790 USA 792 Phone: 793 Email: prenatar@cisco.com 795 Randall R. Stewart 796 Researcher 797 Chapi, SC 29036 798 USA 800 Phone: 202-595-8626 801 Email: randall@lakerest.net 802 Janardhan Iyengar 803 Franklin & Marshall College 804 Math and Computer Science 805 PO Box 3003 806 Lancaster, PA 17604-3003 807 USA 809 Phone: 717-358-4774 810 Email: jiyengar@fandm.edu