idnits 2.17.1 draft-ietf-tsvwg-rfc4960-errata-02.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1630 has weird spacing: '... packet with ...' -- The document date (July 3, 2017) is 2482 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2434' is mentioned on line 249, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'RFC0813' is mentioned on line 407, but not defined ** Obsolete undefined reference: RFC 813 (Obsoleted by RFC 7805) == Missing Reference: 'RFC1858' is mentioned on line 1641, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 4460 (Obsoleted by RFC 9260) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Netflix, Inc. 4 Intended status: Informational M. Tuexen 5 Expires: January 4, 2018 Muenster Univ. of Appl. Sciences 6 M. Proshin 7 Ericsson 8 July 3, 2017 10 RFC 4960 Errata and Issues 11 draft-ietf-tsvwg-rfc4960-errata-02.txt 13 Abstract 15 This document is a compilation of issues found since the publication 16 of RFC4960 in September 2007 based on experience with implementing, 17 testing, and using SCTP along with the suggested fixes. This 18 document provides deltas to RFC4960 and is organized in a time based 19 way. The issues are listed in the order they were brought up. 20 Because some text is changed several times the last delta in the text 21 is the one which should be applied. In addition to the delta a 22 description of the problem and the details of the solution are also 23 provided. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 4, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 4 62 3.1. Path Error Counter Threshold Handling . . . . . . . . . . 4 63 3.2. Upper Layer Protocol Shutdown Request Handling . . . . . 5 64 3.3. Registration of New Chunk Types . . . . . . . . . . . . . 5 65 3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 6 66 3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 7 67 3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 8 68 3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 9 69 3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 10 70 3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 11 71 3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 17 72 3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 18 73 3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 18 74 3.13. HEARTBEAT ACK and the association error counter . . . . . 19 75 3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 21 76 3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 22 77 3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 22 78 3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 23 79 3.18. Only One Packet after Retransmission Timeout . . . . . . 24 80 3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 25 81 3.20. Zero Window Probing and Unreachable Primary Path . . . . 26 82 3.21. Normative Language in Section 10 . . . . . . . . . . . . 27 83 3.22. Increase of partial_bytes_acked in Congestion Avoidance . 31 84 3.23. Inconsistency in Notifications Handling . . . . . . . . . 32 85 3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 36 86 3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 38 87 3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 39 88 3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 41 89 3.28. Window Updates After Receiver Window Opens Up . . . . . . 42 90 3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 43 91 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 45 92 3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 46 93 3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 47 94 3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 49 95 3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 49 96 3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 50 97 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 52 98 3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 54 99 3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 55 100 3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 56 101 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 102 5. Security Considerations . . . . . . . . . . . . . . . . . . . 58 103 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 104 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 105 7.1. Normative References . . . . . . . . . . . . . . . . . . 58 106 7.2. Informative References . . . . . . . . . . . . . . . . . 58 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 109 1. Introduction 111 This document contains a compilation of all defects found up until 112 the publishing of this document for [RFC4960] specifying the Stream 113 Control Transmission Protocol (SCTP). These defects may be of an 114 editorial or technical nature. This document may be thought of as a 115 companion document to be used in the implementation of SCTP to 116 clarify errors in the original SCTP document. 118 This document provides a history of the changes that will be compiled 119 into a BIS document for [RFC4960]. It is structured similar to 120 [RFC4460]. 122 Each error will be detailed within this document in the form of: 124 o The problem description, 125 o The text quoted from [RFC4960], 126 o The replacement text that should be placed into an upcoming BIS 127 document, 128 o A description of the solution. 130 Note that when reading this document one must use care to assure that 131 a field or item is not updated further on within the document. Each 132 section should be applied in sequence to the original [RFC4960] since 133 this document is a historical record of the sequential changes that 134 have been found necessary at various inter-op events and through 135 discussion on the list. 137 2. Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Corrections to RFC 4960 145 3.1. Path Error Counter Threshold Handling 147 3.1.1. Description of the Problem 149 The handling of the 'Path.Max.Retrans' parameter is described in 150 Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way. 151 Whereas Section 8.2 describes that a path is marked inactive when the 152 path error counter exceeds the threshold, Section 8.3 says the path 153 is marked inactive when the path error counter reaches the threshold. 155 This issue was reported as an Errata for [RFC4960] with Errata ID 156 1440. 158 3.1.2. Text Changes to the Document 160 --------- 161 Old text: (Section 8.3) 162 --------- 164 When the value of this counter reaches the protocol parameter 165 'Path.Max.Retrans', the endpoint should mark the corresponding 166 destination address as inactive if it is not so marked, and may also 167 optionally report to the upper layer the change of reachability of 168 this destination address. After this, the endpoint should continue 169 HEARTBEAT on this destination address but should stop increasing the 170 counter. 172 --------- 173 New text: (Section 8.3) 174 --------- 176 When the value of this counter exceeds the protocol parameter 177 'Path.Max.Retrans', the endpoint should mark the corresponding 178 destination address as inactive if it is not so marked, and may also 179 optionally report to the upper layer the change of reachability of 180 this destination address. After this, the endpoint should continue 181 HEARTBEAT on this destination address but should stop increasing the 182 counter. 184 3.1.3. Solution Description 186 The intended state change should happen when the threshold is 187 exceeded. 189 3.2. Upper Layer Protocol Shutdown Request Handling 191 3.2.1. Description of the Problem 193 Section 9.2 of [RFC4960] describes the handling of received SHUTDOWN 194 chunks in the SHUTDOWN-RECEIVED state instead of the handling of 195 shutdown requests from its upper layer in this state. 197 This issue was reported as an Errata for [RFC4960] with Errata ID 198 1574. 200 3.2.2. Text Changes to the Document 202 --------- 203 Old text: (Section 9.2) 204 --------- 206 Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT 207 send a SHUTDOWN in response to a ULP request, and should discard 208 subsequent SHUTDOWN chunks. 210 --------- 211 New text: (Section 9.2) 212 --------- 214 Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT 215 send a SHUTDOWN in response to a ULP request, and should discard 216 subsequent ULP shutdown requests. 218 3.2.3. Solution Description 220 The text never intended the SCTP endpoint to ignore SHUTDOWN chunks 221 from its peer. If it did the endpoints could never gracefully 222 terminate associations in some cases. 224 3.3. Registration of New Chunk Types 226 3.3.1. Description of the Problem 228 Section 14.1 of [RFC4960] should deal with new chunk types, however, 229 the text refers to parameter types. 231 This issue was reported as an Errata for [RFC4960] with Errata ID 232 2592. 234 3.3.2. Text Changes to the Document 236 --------- 237 Old text: (Section 14.1) 238 --------- 240 The assignment of new chunk parameter type codes is done through an 241 IETF Consensus action, as defined in [RFC2434]. Documentation of the 242 chunk parameter MUST contain the following information: 244 --------- 245 New text: (Section 14.1) 246 --------- 248 The assignment of new chunk type codes is done through an 249 IETF Consensus action, as defined in [RFC2434]. Documentation of the 250 chunk type MUST contain the following information: 252 3.3.3. Solution Description 254 Refer to chunk types as intended. 256 3.4. Variable Parameters for INIT Chunks 258 3.4.1. Description of the Problem 260 Newlines in wrong places break the layout of the table of variable 261 parameters for the INIT chunk in Section 3.3.2 of [RFC4960]. 263 This issue was reported as an Errata for [RFC4960] with Errata ID 264 3291 and Errata ID 3804. 266 3.4.2. Text Changes to the Document 267 --------- 268 Old text: (Section 3.3.2) 269 --------- 271 Variable Parameters Status Type Value 272 ------------------------------------------------------------- 273 IPv4 Address (Note 1) Optional 5 IPv6 Address 274 (Note 1) Optional 6 Cookie Preservative 275 Optional 9 Reserved for ECN Capable (Note 2) Optional 276 32768 (0x8000) Host Name Address (Note 3) Optional 277 11 Supported Address Types (Note 4) Optional 12 279 --------- 280 New text: (Section 3.3.2) 281 --------- 283 Variable Parameters Status Type Value 284 ------------------------------------------------------------- 285 IPv4 Address (Note 1) Optional 5 286 IPv6 Address (Note 1) Optional 6 287 Cookie Preservative Optional 9 288 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) 289 Host Name Address (Note 3) Optional 11 290 Supported Address Types (Note 4) Optional 12 292 3.4.3. Solution Description 294 Fix the formatting of the table. 296 3.5. CRC32c Sample Code on 64-bit Platforms 298 3.5.1. Description of the Problem 300 The sample code for computing the CRC32c provided in [RFC4960] 301 assumes that a variable of type unsigned long uses 32 bits. This is 302 not true on some 64-bit platforms (for example the ones using LP64). 304 This issue was reported as an Errata for [RFC4960] with Errata ID 305 3423. 307 3.5.2. Text Changes to the Document 308 --------- 309 Old text: (Appendix C) 310 --------- 312 unsigned long 313 generate_crc32c(unsigned char *buffer, unsigned int length) 314 { 315 unsigned int i; 316 unsigned long crc32 = ~0L; 318 --------- 319 New text: (Appendix C) 320 --------- 322 unsigned long 323 generate_crc32c(unsigned char *buffer, unsigned int length) 324 { 325 unsigned int i; 326 unsigned long crc32 = 0xffffffffL; 328 3.5.3. Solution Description 330 Use 0xffffffffL instead of ~0L which gives the same value on 331 platforms using 32 bits or 64 bits for variables of type unsigned 332 long. 334 3.6. Endpoint Failure Detection 336 3.6.1. Description of the Problem 338 The handling of the association error counter defined in Section 8.1 339 of [RFC4960] can result in an association failure even if the path 340 used for data transmission is available, but idle. 342 This issue was reported as an Errata for [RFC4960] with Errata ID 343 3788. 345 3.6.2. Text Changes to the Document 346 --------- 347 Old text: (Section 8.1) 348 --------- 350 An endpoint shall keep a counter on the total number of consecutive 351 retransmissions to its peer (this includes retransmissions to all the 352 destination transport addresses of the peer if it is multi-homed), 353 including unacknowledged HEARTBEAT chunks. 355 --------- 356 New text: (Section 8.1) 357 --------- 359 An endpoint shall keep a counter on the total number of consecutive 360 retransmissions to its peer (this includes data retransmissions 361 to all the destination transport addresses of the peer if it is 362 multi-homed), including the number of unacknowledged HEARTBEAT 363 chunks observed on the path which currently is used for data 364 transfer. Unacknowledged HEARTBEAT chunks observed on paths 365 different from the path currently used for data transfer shall 366 not increment the association error counter, as this could lead 367 to association closure even if the path which currently is used for 368 data transfer is available (but idle). 370 3.6.3. Solution Description 372 A more refined handling for the association error counter is defined. 374 3.7. Data Transmission Rules 376 3.7.1. Description of the Problem 378 When integrating the changes to Section 6.1 A) of [RFC2960] as 379 described in Section 2.15.2 of [RFC4460] some text was duplicated and 380 became the final paragraph of Section 6.1 A) of [RFC4960]. 382 This issue was reported as an Errata for [RFC4960] with Errata ID 383 4071. 385 3.7.2. Text Changes to the Document 386 --------- 387 Old text: (Section 6.1 A)) 388 --------- 390 The sender MUST also have an algorithm for sending new DATA chunks 391 to avoid silly window syndrome (SWS) as described in [RFC0813]. 392 The algorithm can be similar to the one described in Section 393 4.2.3.4 of [RFC1122]. 395 However, regardless of the value of rwnd (including if it is 0), 396 the data sender can always have one DATA chunk in flight to the 397 receiver if allowed by cwnd (see rule B below). This rule allows 398 the sender to probe for a change in rwnd that the sender missed 399 due to the SACK having been lost in transit from the data receiver 400 to the data sender. 402 --------- 403 New text: (Section 6.1 A)) 404 --------- 406 The sender MUST also have an algorithm for sending new DATA chunks 407 to avoid silly window syndrome (SWS) as described in [RFC0813]. 408 The algorithm can be similar to the one described in Section 409 4.2.3.4 of [RFC1122]. 411 3.7.3. Solution Description 413 Last paragraph of Section 6.1 A) removed as intended in 414 Section 2.15.2 of [RFC4460]. 416 3.8. T1-Cookie Timer 418 3.8.1. Description of the Problem 420 Figure 4 of [RFC4960] illustrates the SCTP association setup. 421 However, it incorrectly shows that the T1-init timer is used in the 422 COOKIE-ECHOED state whereas the T1-cookie timer should have been used 423 instead. 425 This issue was reported as an Errata for [RFC4960] with Errata ID 426 4400. 428 3.8.2. Text Changes to the Document 429 --------- 430 Old text: (Section 5.1.6, Figure 4) 431 --------- 433 COOKIE ECHO [Cookie_Z] ------\ 434 (Start T1-init timer) \ 435 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 436 state) 437 /---- COOKIE-ACK 438 / 439 (Cancel T1-init timer, <-----/ 440 Enter ESTABLISHED state) 442 --------- 443 New text: (Section 5.1.6, Figure 4) 444 --------- 446 COOKIE ECHO [Cookie_Z] ------\ 447 (Start T1-cookie timer) \ 448 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 449 state) 450 /---- COOKIE-ACK 451 / 452 (Cancel T1-cookie timer, <---/ 453 Enter ESTABLISHED state) 455 3.8.3. Solution Description 457 Change the figure such that the T1-cookie timer is used instead of 458 the T1-init timer. 460 3.9. Miscellaneous Typos 462 3.9.1. Description of the Problem 464 While processing [RFC4960] some typos were not catched. 466 3.9.2. Text Changes to the Document 467 --------- 468 Old text: (Section 1.6) 469 --------- 471 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 472 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 473 2*32 - 1 is TSN = 0. 475 --------- 476 New text: (Section 1.6) 477 --------- 479 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 480 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 481 2**32 - 1 is TSN = 0. 483 --------- 484 Old text: (Section 3.3.10.9) 485 --------- 487 No User Data: This error cause is returned to the originator of a 489 DATA chunk if a received DATA chunk has no user data. 491 --------- 492 New text: (Section 3.3.10.9) 493 --------- 495 No User Data: This error cause is returned to the originator of a 496 DATA chunk if a received DATA chunk has no user data. 498 --------- 499 Old text: (Section 6.7, Figure 9) 500 --------- 502 Endpoint A Endpoint Z {App 503 sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ---------- 504 -----> (ack delayed) (Start T3-rtx timer) 506 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 508 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 509 immediately send ack) 510 /----- SACK [TSN Ack=6,Block=1, 511 / Start=2,End=2] 512 <-----/ (remove 6 from out-queue, 513 and mark 7 as "1" missing report) 515 --------- 516 New text: (Section 6.7, Figure 9) 517 --------- 519 Endpoint A Endpoint Z 520 {App sends 3 messages; strm 0} 521 DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed) 522 (Start T3-rtx timer) 524 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 526 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 527 immediately send ack) 528 /----- SACK [TSN Ack=6,Block=1, 529 / Strt=2,End=2] 530 <-----/ 531 (remove 6 from out-queue, 532 and mark 7 as "1" missing report) 534 --------- 535 Old text: (Section 6.10) 536 --------- 538 An endpoint bundles chunks by simply including multiple chunks in one 539 outbound SCTP packet. The total size of the resultant IP datagram, 541 including the SCTP packet and IP headers, MUST be less that or equal 542 to the current Path MTU. 544 --------- 545 New text: (Section 6.10) 546 --------- 548 An endpoint bundles chunks by simply including multiple chunks in one 549 outbound SCTP packet. The total size of the resultant IP datagram, 550 including the SCTP packet and IP headers, MUST be less than or equal 551 to the current Path MTU. 553 --------- 554 Old text: (Section 10.1) 555 --------- 557 o Receive Unacknowledged Message 559 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 560 size, [,stream id] [, stream sequence number] [,partial 561 flag] [,payload protocol-id]) 563 --------- 564 New text: (Section 10.1) 565 --------- 567 O) Receive Unacknowledged Message 569 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 570 size, [,stream id] [, stream sequence number] [,partial 571 flag] [,payload protocol-id]) 573 --------- 574 Old text: (Appendix C) 575 --------- 577 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 578 type field is not "Destination Unreachable", "Parameter 579 Problem",, or "Packet Too Big". 581 --------- 582 New text: (Appendix C) 583 --------- 585 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 586 type field is not "Destination Unreachable", "Parameter 587 Problem", or "Packet Too Big". 589 --------- 590 Old text: (Section 5.4) 591 --------- 593 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 594 is the one to which the INIT-ACK was sent. 596 --------- 597 New text: (Section 5.4) 598 --------- 600 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 601 is the one to which the INIT ACK was sent. 603 --------- 604 Old text: (Section 5.1.6, Figure 4) 605 --------- 607 COOKIE ECHO [Cookie_Z] ------\ 608 (Start T1-init timer) \ 609 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 610 state) 611 /---- COOKIE-ACK 612 / 613 (Cancel T1-init timer, <-----/ 614 Enter ESTABLISHED state) 616 --------- 617 New text: (Section 5.1.6, Figure 4) 618 --------- 620 COOKIE ECHO [Cookie_Z] ------\ 621 (Start T1-cookie timer) \ 622 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 623 state) 624 /---- COOKIE ACK 625 / 626 (Cancel T1-cookie timer, <---/ 627 Enter ESTABLISHED state) 629 --------- 630 Old text: (Section 5.2.5) 631 --------- 633 5.2.5. Handle Duplicate COOKIE-ACK. 635 --------- 636 New text: (Section 5.2.5) 637 --------- 639 5.2.5. Handle Duplicate COOKIE ACK. 641 --------- 642 Old text: (Section 8.3) 643 --------- 645 By default, an SCTP endpoint SHOULD monitor the reachability of the 646 idle destination transport address(es) of its peer by sending a 647 HEARTBEAT chunk periodically to the destination transport 648 address(es). HEARTBEAT sending MAY begin upon reaching the 649 ESTABLISHED state and is discontinued after sending either SHUTDOWN 650 or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a 651 HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state 652 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 653 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 654 ACK-SENT state (SHUTDOWN receiver). 656 --------- 657 New text: (Section 8.3) 658 --------- 659 By default, an SCTP endpoint SHOULD monitor the reachability of the 660 idle destination transport address(es) of its peer by sending a 661 HEARTBEAT chunk periodically to the destination transport 662 address(es). HEARTBEAT sending MAY begin upon reaching the 663 ESTABLISHED state and is discontinued after sending either SHUTDOWN 664 or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a 665 HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state 666 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 667 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 668 ACK-SENT state (SHUTDOWN receiver). 670 3.9.3. Solution Description 672 Typos fixed. 674 3.10. CRC32c Sample Code 676 3.10.1. Description of the Problem 678 The CRC32c computation is described in Appendix B of [RFC4960]. 679 However, the corresponding sample code and its explanation appears at 680 the end of Appendix C, which deals with ICMP handling. 682 3.10.2. Text Changes to the Document 684 Move the sample code related to CRC32c computation and its 685 explanation from the end of Appendix C to the end of Appendix B. 687 3.10.3. Solution Description 689 Text moved to the appropriate location. 691 3.11. partial_bytes_acked after T3-rtx Expiration 693 3.11.1. Description of the Problem 695 Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked 696 should be reset to 0 after packet loss detecting from SACK but the 697 same is missed for T3-rtx timer expiration. 699 3.11.2. Text Changes to the Document 701 --------- 702 Old text: (Section 7.2.3) 703 --------- 705 When the T3-rtx timer expires on an address, SCTP should perform slow 706 start by: 708 ssthresh = max(cwnd/2, 4*MTU) 709 cwnd = 1*MTU 711 --------- 712 New text: (Section 7.2.3) 713 --------- 715 When the T3-rtx timer expires on an address, SCTP should perform slow 716 start by: 718 ssthresh = max(cwnd/2, 4*MTU) 719 cwnd = 1*MTU 720 partial_bytes_acked = 0 722 3.11.3. Solution Description 724 Specify that partial_bytes_acked should be reset to 0 after T3-rtx 725 timer expiration. 727 3.12. Order of Adjustments of partial_bytes_acked and cwnd 729 3.12.1. Description of the Problem 731 Section 7.2.2 of [RFC4960] is unclear about the order of adjustments 732 applied to partial_bytes_acked and cwnd in the congestion avoidance 733 phase. 735 3.12.2. Text Changes to the Document 737 --------- 738 Old text: (Section 7.2.2) 739 --------- 741 o When partial_bytes_acked is equal to or greater than cwnd and 742 before the arrival of the SACK the sender had cwnd or more bytes 743 of data outstanding (i.e., before arrival of the SACK, flightsize 744 was greater than or equal to cwnd), increase cwnd by MTU, and 745 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 747 --------- 748 New text: (Section 7.2.2) 749 --------- 751 o When partial_bytes_acked is equal to or greater than cwnd and 752 before the arrival of the SACK the sender had cwnd or more bytes 753 of data outstanding (i.e., before arrival of the SACK, flightsize 754 was greater than or equal to cwnd), partial_bytes_acked is reset 755 to (partial_bytes_acked - cwnd). Next, cwnd is increased by MTU. 757 3.12.3. Solution Description 759 The new text defines the exact order of adjustments of 760 partial_bytes_acked and cwnd in the congestion avoidance phase. 762 3.13. HEARTBEAT ACK and the association error counter 764 3.13.1. Description of the Problem 766 Section 8.1 and Section 8.3 of [RFC4960] prescribe that the receiver 767 of a HEARTBEAT ACK must reset the association overall error counter. 768 In some circumstances, e.g. when a router discards DATA chunks but 769 not HEARTBEAT chunks due to the larger size of the DATA chunk, it 770 might be better to not clear the association error counter on 771 reception of the HEARTBEAT ACK and reset it only on reception of the 772 SACK to avoid stalling the association. 774 3.13.2. Text Changes to the Document 775 --------- 776 Old text: (Section 8.1) 777 --------- 779 The counter shall be reset each time a DATA chunk sent to that peer 780 endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT 781 ACK is received from the peer endpoint. 783 --------- 784 New text: (Section 8.1) 785 --------- 787 The counter shall be reset each time a DATA chunk sent to that peer 788 endpoint is acknowledged (by the reception of a SACK). When a 789 HEARTBEAT ACK is received from the peer endpoint, the counter should 790 also be reset. The receiver of the HEARTBEAT ACK may choose not to 791 clear the counter if there is outstanding data on the association. 792 This allows for handling the possible difference in reachability 793 based on DATA chunks and HEARTBEAT chunks. 795 --------- 796 Old text: (Section 8.3) 797 --------- 799 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 800 should clear the error counter of the destination transport address 801 to which the HEARTBEAT was sent, and mark the destination transport 802 address as active if it is not so marked. The endpoint may 803 optionally report to the upper layer when an inactive destination 804 address is marked as active due to the reception of the latest 805 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 806 association overall error count as well (as defined in Section 8.1). 808 --------- 809 New text: (Section 8.3) 810 --------- 812 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 813 should clear the error counter of the destination transport address 814 to which the HEARTBEAT was sent, and mark the destination transport 815 address as active if it is not so marked. The endpoint may 816 optionally report to the upper layer when an inactive destination 817 address is marked as active due to the reception of the latest 818 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK should also clear 819 the association overall error counter (as defined in Section 8.1). 821 3.13.3. Solution Description 823 The new text provides a possibility to not reset the association 824 overall error counter when a HEARTBEAT ACK is received if there are 825 valid reasons for it. 827 3.14. Path for Fast Retransmission 829 3.14.1. Description of the Problem 831 [RFC4960] clearly describes where to retransmit data that is timed 832 out when the peer is multi-homed but the same is not stated for fast 833 retransmissions. 835 3.14.2. Text Changes to the Document 837 --------- 838 Old text: (Section 6.4) 839 --------- 841 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 842 retransmit a chunk that timed out to an active destination transport 843 address that is different from the last destination address to which 844 the DATA chunk was sent. 846 --------- 847 New text: (Section 6.4) 848 --------- 850 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 851 retransmit a chunk that timed out to an active destination transport 852 address that is different from the last destination address to which 853 the DATA chunk was sent. 855 When its peer is multi-homed, an endpoint SHOULD send fast 856 retransmissions to the same destination transport address where 857 original data was sent to. If the primary path has been changed and 858 original data was sent there before the fast retransmit, the 859 implementation MAY send it to the new primary path. 861 3.14.3. Solution Description 863 The new text clarifies where to send fast retransmissions. 865 3.15. Transmittal in Fast Recovery 867 3.15.1. Description of the Problem 869 The Fast Retransmit on Gap Reports algorithm intends that only the 870 very first packet may be sent regardless of cwnd in the Fast Recovery 871 phase but rule 3) of [RFC4960], Section 7.2.4, misses this 872 clarification. 874 3.15.2. Text Changes to the Document 876 --------- 877 Old text: (Section 7.2.4) 878 --------- 880 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 881 marked for retransmission will fit into a single packet, subject 882 to constraint of the path MTU of the destination transport 883 address to which the packet is being sent. Call this value K. 884 Retransmit those K DATA chunks in a single packet. When a Fast 885 Retransmit is being performed, the sender SHOULD ignore the value 886 of cwnd and SHOULD NOT delay retransmission for this single 887 packet. 889 --------- 890 New text: (Section 7.2.4) 891 --------- 893 3) If not in Fast Recovery, determine how many of the earliest 894 (i.e., lowest TSN) DATA chunks marked for retransmission will fit 895 into a single packet, subject to constraint of the path MTU of 896 the destination transport address to which the packet is being 897 sent. Call this value K. Retransmit those K DATA chunks in a 898 single packet. When a Fast Retransmit is being performed, the 899 sender SHOULD ignore the value of cwnd and SHOULD NOT delay 900 retransmission for this single packet. 902 3.15.3. Solution Description 904 The new text explicitly specifies to send only the first packet in 905 the Fast Recovery phase disregarding cwnd limitations. 907 3.16. Initial Value of ssthresh 908 3.16.1. Description of the Problem 910 The initial value of ssthresh should be set arbitrarily high. Using 911 the advertised receiver window of the peer is inappropriate if the 912 peer increases its window after the handshake. Furthermore, use a 913 higher requirements level, since not following the advice may result 914 in performance problems. 916 3.16.2. Text Changes to the Document 918 --------- 919 Old text: (Section 7.2.1) 920 --------- 922 o The initial value of ssthresh MAY be arbitrarily high (for 923 example, implementations MAY use the size of the receiver 924 advertised window). 926 --------- 927 New text: (Section 7.2.1) 928 --------- 930 o The initial value of ssthresh SHOULD be arbitrarily high (e.g., 931 to the size of the largest possible advertised window). 933 3.16.3. Solution Description 935 Use the same value as suggested in [RFC5681], Section 3.1, as an 936 appropriate initial value. Furthermore use the same requirements 937 level. 939 3.17. Automatically Confirmed Addresses 941 3.17.1. Description of the Problem 943 The Path Verification procedure of [RFC4960] prescribes that any 944 address passed to the sender of the INIT by its upper layer is 945 automatically CONFIRMED. This however is unclear if only addresses 946 in the request to initiate association establishment are considered 947 or any addresses provided by the upper layer in any requests (e.g. in 948 'Set Primary'). 950 3.17.2. Text Changes to the Document 951 --------- 952 Old text: (Section 5.4) 953 --------- 955 1) Any address passed to the sender of the INIT by its upper layer 956 is automatically considered to be CONFIRMED. 958 --------- 959 New text: (Section 5.4) 960 --------- 962 1) Any addresses passed to the sender of the INIT by its upper 963 layer in the request to initialize an association is 964 automatically considered to be CONFIRMED. 966 3.17.3. Solution Description 968 The new text clarifies that only addresses provided by the upper 969 layer in the request to initialize an association are automatically 970 confirmed. 972 3.18. Only One Packet after Retransmission Timeout 974 3.18.1. Description of the Problem 976 [RFC4960] is not completely clear when it describes data transmission 977 after T3-rtx timer expiration. Section 7.2.1 does not specify how 978 many packets are allowed to be sent after T3-rtx timer expiration if 979 more than one packet fit into cwnd. At the same time, Section 7.2.3 980 has the text without normative language saying that SCTP should 981 ensure that no more than one packet will be in flight after T3-rtx 982 timer expiration until successful acknowledgment. It makes the text 983 inconsistent. 985 3.18.2. Text Changes to the Document 986 --------- 987 Old text: (Section 7.2.1) 988 --------- 990 o The initial cwnd after a retransmission timeout MUST be no more 991 than 1*MTU. 993 --------- 994 New text: (Section 7.2.1) 995 --------- 997 o The initial cwnd after a retransmission timeout MUST be no more 998 than 1*MTU and only one packet is allowed to be in flight 999 until successful acknowledgement. 1001 3.18.3. Solution Description 1003 The new text clearly specifies that only one packet is allowed to be 1004 sent after T3-rtx timer expiration until successful acknowledgement. 1006 3.19. INIT ACK Path for INIT in COOKIE-WAIT State 1008 3.19.1. Description of the Problem 1010 In case of an INIT received in the COOKIE-WAIT state [RFC4960] 1011 prescribes to send an INIT ACK to the same destination address to 1012 which the original INIT has been sent. This text does not address 1013 the possibility of the upper layer to provide multiple remote IP 1014 addresses while requesting the association establishment. If the 1015 upper layer has provided multiple IP addresses and only a subset of 1016 these addresses are supported by the peer then the destination 1017 address of the original INIT may be absent in the incoming INIT and 1018 sending INIT ACK to that address is useless. 1020 3.19.2. Text Changes to the Document 1021 --------- 1022 Old text: (Section 5.2.1) 1023 --------- 1025 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1026 respond with an INIT ACK using the same parameters it sent in its 1027 original INIT chunk (including its Initiate Tag, unchanged). When 1028 responding, the endpoint MUST send the INIT ACK back to the same 1029 address that the original INIT (sent by this endpoint) was sent. 1031 --------- 1032 New text: (Section 5.2.1) 1033 --------- 1035 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1036 respond with an INIT ACK using the same parameters it sent in its 1037 original INIT chunk (including its Initiate Tag, unchanged). When 1038 responding, the following rules MUST be applied: 1040 1) The INIT ACK MUST only be sent to an address passed by the upper 1041 layer in the request to initialize the association. 1043 2) The INIT ACK MUST only be sent to an address reported in the 1044 incoming INIT. 1046 3) The INIT ACK SHOULD be sent to the source address of the 1047 received INIT. 1049 3.19.3. Solution Description 1051 The new text requires sending INIT ACK to the destination address 1052 that is passed by the upper layer and reported in the incoming INIT. 1053 If the source address of the INIT fulfills it then sending the INIT 1054 ACK to the source address of the INIT is the preferred behavior. 1056 3.20. Zero Window Probing and Unreachable Primary Path 1058 3.20.1. Description of the Problem 1060 Section 6.1 of [RFC4960] states that when sending zero window probes, 1061 SCTP should neither increment the association counter nor increment 1062 the destination address error counter if it continues to receive new 1063 packets from the peer. But receiving new packets from the peer does 1064 not guarantee peer's accessibility and, if the destination address 1065 becomes unreachable during zero window probing, SCTP cannot get a 1066 changed rwnd until it switches the destination address for probes. 1068 3.20.2. Text Changes to the Document 1070 --------- 1071 Old text: (Section 6.1) 1072 --------- 1074 If the sender continues to receive new packets from the receiver 1075 while doing zero window probing, the unacknowledged window probes 1076 should not increment the error counter for the association or any 1077 destination transport address. This is because the receiver MAY 1078 keep its window closed for an indefinite time. Refer to Section 1079 6.2 on the receiver behavior when it advertises a zero window. 1081 --------- 1082 New text: (Section 6.1) 1083 --------- 1085 If the sender continues to receive SACKs from the peer 1086 while doing zero window probing, the unacknowledged window probes 1087 should not increment the error counter for the association or any 1088 destination transport address. This is because the receiver MAY 1089 keep its window closed for an indefinite time. Refer to Section 1090 6.2 on the receiver behavior when it advertises a zero window. 1092 3.20.3. Solution Description 1094 The new text clarifies that if the receiver continues to send SACKs, 1095 the sender of probes should not increment the error counter of the 1096 association and the destination address even if the SACKs do not 1097 acknowledge the probes. 1099 3.21. Normative Language in Section 10 1101 3.21.1. Description of the Problem 1103 Section 10 of [RFC4960] is informative and normative language such as 1104 MUST and MAY cannot be used there. However, there are several places 1105 in Section 10 where MUST and MAY are used. 1107 3.21.2. Text Changes to the Document 1109 --------- 1110 Old text: (Section 10.1) 1111 --------- 1113 E) Send 1115 Format: SEND(association id, buffer address, byte count [,context] 1117 [,stream id] [,life time] [,destination transport address] 1118 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 1119 -> result 1121 ... 1123 o no-bundle flag - instructs SCTP not to bundle this user data with 1124 other outbound DATA chunks. SCTP MAY still bundle even when this 1125 flag is present, when faced with network congestion. 1127 --------- 1128 New text: (Section 10.1) 1129 --------- 1131 E) Send 1133 Format: SEND(association id, buffer address, byte count [,context] 1134 [,stream id] [,life time] [,destination transport address] 1135 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 1136 -> result 1138 ... 1140 o no-bundle flag - instructs SCTP not to bundle this user data with 1141 other outbound DATA chunks. SCTP may still bundle even when this 1142 flag is present, when faced with network congestion. 1144 --------- 1145 Old text: (Section 10.1) 1146 --------- 1148 G) Receive 1150 Format: RECEIVE(association id, buffer address, buffer size 1151 [,stream id]) 1152 -> byte count [,transport address] [,stream id] [,stream sequence 1153 number] [,partial flag] [,delivery number] [,payload protocol-id] 1155 ... 1157 o partial flag - if this returned flag is set to 1, then this 1158 Receive contains a partial delivery of the whole message. When 1159 this flag is set, the stream id and Stream Sequence Number MUST 1160 accompany this receive. When this flag is set to 0, it indicates 1161 that no more deliveries will be received for this Stream Sequence 1162 Number. 1164 --------- 1165 New text: (Section 10.1) 1166 --------- 1168 G) Receive 1170 Format: RECEIVE(association id, buffer address, buffer size 1171 [,stream id]) 1172 -> byte count [,transport address] [,stream id] [,stream sequence 1173 number] [,partial flag] [,delivery number] [,payload protocol-id] 1175 ... 1177 o partial flag - if this returned flag is set to 1, then this 1178 Receive contains a partial delivery of the whole message. When 1179 this flag is set, the stream id and Stream Sequence Number must 1180 accompany this receive. When this flag is set to 0, it indicates 1181 that no more deliveries will be received for this Stream Sequence 1182 Number. 1184 --------- 1185 Old text: (Section 10.1) 1186 --------- 1188 N) Receive Unsent Message 1190 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer 1191 size [,stream id] [, stream sequence number] [,partial 1192 flag] [,payload protocol-id]) 1194 ... 1196 o partial flag - if this returned flag is set to 1, then this 1197 message is a partial delivery of the whole message. When this 1198 flag is set, the stream id and Stream Sequence Number MUST 1199 accompany this receive. When this flag is set to 0, it indicates 1200 that no more deliveries will be received for this Stream Sequence 1201 Number. 1203 --------- 1204 New text: (Section 10.1) 1205 --------- 1207 N) Receive Unsent Message 1209 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer 1210 size [,stream id] [, stream sequence number] [,partial 1211 flag] [,payload protocol-id]) 1213 ... 1215 o partial flag - if this returned flag is set to 1, then this 1216 message is a partial delivery of the whole message. When this 1217 flag is set, the stream id and Stream Sequence Number must 1218 accompany this receive. When this flag is set to 0, it indicates 1219 that no more deliveries will be received for this Stream Sequence 1220 Number. 1222 --------- 1223 Old text: (Section 10.1) 1224 --------- 1226 O) Receive Unacknowledged Message 1228 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 1229 size, [,stream id] [, stream sequence number] [,partial 1230 flag] [,payload protocol-id]) 1232 ... 1234 o partial flag - if this returned flag is set to 1, then this 1235 message is a partial delivery of the whole message. When this 1236 flag is set, the stream id and Stream Sequence Number MUST 1237 accompany this receive. When this flag is set to 0, it indicates 1238 that no more deliveries will be received for this Stream Sequence 1239 Number. 1241 --------- 1242 New text: (Section 10.1) 1243 --------- 1245 O) Receive Unacknowledged Message 1247 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 1248 size, [,stream id] [, stream sequence number] [,partial 1249 flag] [,payload protocol-id]) 1251 ... 1253 o partial flag - if this returned flag is set to 1, then this 1254 message is a partial delivery of the whole message. When this 1255 flag is set, the stream id and Stream Sequence Number must 1256 accompany this receive. When this flag is set to 0, it indicates 1257 that no more deliveries will be received for this Stream Sequence 1258 Number. 1260 3.21.3. Solution Description 1262 The normative language is removed from Section 10. 1264 3.22. Increase of partial_bytes_acked in Congestion Avoidance 1266 3.22.1. Description of the Problem 1268 Two issues have been discovered with the partial_bytes_acked handling 1269 described in Section 7.2.2 of [RFC4960]: 1271 o If the Cumulative TSN Ack Point is not advanced but the SACK chunk 1272 acknowledges new TSNs in the Gap Ack Blocks, these newly 1273 acknowledged TSNs are not considered for partial_bytes_acked 1274 although these TSNs were successfully received by the peer. 1275 o Duplicate TSNs are not considered in partial_bytes_acked although 1276 they confirm that the DATA chunks were successfully received by 1277 the peer. 1279 3.22.2. Text Changes to the Document 1281 --------- 1282 Old text: (Section 7.2.2) 1283 --------- 1285 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1286 that advances the Cumulative TSN Ack Point, increase 1287 partial_bytes_acked by the total number of bytes of all new chunks 1288 acknowledged in that SACK including chunks acknowledged by the new 1289 Cumulative TSN Ack and by Gap Ack Blocks. 1291 --------- 1292 New text: (Section 7.2.2) 1293 --------- 1295 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1296 increase partial_bytes_acked by the total number of bytes of all 1297 new chunks acknowledged in that SACK including chunks acknowledged 1298 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1299 of bytes of duplicated chunks reported in Duplicate TSNs. 1301 3.22.3. Solution Description 1303 Now partial_bytes_acked is increased by TSNs reported as duplicated 1304 as well as TSNs newly acknowledged in Gap Ack Blocks even if the 1305 Cumulative TSN Ack Point is not advanced. 1307 3.23. Inconsistency in Notifications Handling 1309 3.23.1. Description of the Problem 1311 [RFC4960] uses inconsistent normative and non-normative language when 1312 describing rules for sending notifications to the upper layer. E.g. 1313 Section 8.2 of [RFC4960] says that when a destination address becomes 1314 inactive due to an unacknowledged DATA chunk or HEARTBEAT chunk, SCTP 1315 SHOULD send a notification to the upper layer while Section 8.3 of 1316 [RFC4960] says that when a destination address becomes inactive due 1317 to an unacknowledged HEARTBEAT chunk, SCTP may send a notification to 1318 the upper layer. 1320 This makes the text inconsistent. 1322 3.23.2. Text Changes to the Document 1324 The following cahnge is based on the change described in Section 3.6. 1326 --------- 1327 Old text: (Section 8.1) 1328 --------- 1330 An endpoint shall keep a counter on the total number of consecutive 1331 retransmissions to its peer (this includes data retransmissions 1332 to all the destination transport addresses of the peer if it is 1333 multi-homed), including the number of unacknowledged HEARTBEAT 1334 chunks observed on the path which currently is used for data 1335 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1336 different from the path currently used for data transfer shall 1337 not increment the association error counter, as this could lead 1338 to association closure even if the path which currently is used for 1339 data transfer is available (but idle). If the value of this 1340 counter exceeds the limit indicated in the protocol parameter 1341 'Association.Max.Retrans', the endpoint shall consider the peer 1342 endpoint unreachable and shall stop transmitting any more data to it 1343 (and thus the association enters the CLOSED state). In addition, the 1344 endpoint MAY report the failure to the upper layer and optionally 1345 report back all outstanding user data remaining in its outbound 1346 queue. The association is automatically closed when the peer 1347 endpoint becomes unreachable. 1349 --------- 1350 New text: (Section 8.1) 1351 --------- 1353 An endpoint shall keep a counter on the total number of consecutive 1354 retransmissions to its peer (this includes data retransmissions 1355 to all the destination transport addresses of the peer if it is 1356 multi-homed), including the number of unacknowledged HEARTBEAT 1357 chunks observed on the path which currently is used for data 1358 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1359 different from the path currently used for data transfer shall 1360 not increment the association error counter, as this could lead 1361 to association closure even if the path which currently is used for 1362 data transfer is available (but idle). If the value of this 1363 counter exceeds the limit indicated in the protocol parameter 1364 'Association.Max.Retrans', the endpoint shall consider the peer 1365 endpoint unreachable and shall stop transmitting any more data to it 1366 (and thus the association enters the CLOSED state). In addition, the 1367 endpoint SHOULD report the failure to the upper layer and optionally 1368 report back all outstanding user data remaining in its outbound 1369 queue. The association is automatically closed when the peer 1370 endpoint becomes unreachable. 1372 The following changes are based on [RFC4960]. 1374 --------- 1375 Old text: (Section 8.2) 1376 --------- 1378 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1379 address is acknowledged with a HEARTBEAT ACK, the endpoint shall 1380 clear the error counter of the destination transport address to which 1381 the DATA chunk was last sent (or HEARTBEAT was sent). When the peer 1382 endpoint is multi-homed and the last chunk sent to it was a 1383 retransmission to an alternate address, there exists an ambiguity as 1384 to whether or not the acknowledgement should be credited to the 1385 address of the last chunk sent. However, this ambiguity does not 1386 seem to bear any significant consequence to SCTP behavior. If this 1387 ambiguity is undesirable, the transmitter may choose not to clear the 1388 error counter if the last chunk sent was a retransmission. 1390 --------- 1391 New text: (Section 8.2) 1392 --------- 1394 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1395 address is acknowledged with a HEARTBEAT ACK, the endpoint shall 1396 clear the error counter of the destination transport address to which 1397 the DATA chunk was last sent (or HEARTBEAT was sent), and SHOULD 1398 also report to the upper layer when an inactive destination address 1399 is marked as active. When the peer endpoint is multi-homed and the 1400 last chunk sent to it was a retransmission to an alternate address, 1401 there exists an ambiguity as to whether or not the acknowledgement 1402 should be credited to the address of the last chunk sent. However, 1403 this ambiguity does not seem to bear any significant consequence to 1404 SCTP behavior. If this ambiguity is undesirable, the transmitter may 1405 choose not to clear the error counter if the last chunk sent was a 1406 retransmission. 1408 --------- 1409 Old text: (Section 8.3) 1410 --------- 1412 When the value of this counter reaches the protocol parameter 1413 'Path.Max.Retrans', the endpoint should mark the corresponding 1414 destination address as inactive if it is not so marked, and may also 1415 optionally report to the upper layer the change of reachability of 1416 this destination address. After this, the endpoint should continue 1417 HEARTBEAT on this destination address but should stop increasing the 1418 counter. 1420 --------- 1421 New text: (Section 8.3) 1422 --------- 1424 When the value of this counter exceeds the protocol parameter 1425 'Path.Max.Retrans', the endpoint should mark the corresponding 1426 destination address as inactive if it is not so marked, and SHOULD 1427 also report to the upper layer the change of reachability of this 1428 destination address. After this, the endpoint should continue 1429 HEARTBEAT on this destination address but should stop increasing the 1430 counter. 1432 --------- 1433 Old text: (Section 8.3) 1434 --------- 1436 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1437 should clear the error counter of the destination transport address 1438 to which the HEARTBEAT was sent, and mark the destination transport 1439 address as active if it is not so marked. The endpoint may 1440 optionally report to the upper layer when an inactive destination 1441 address is marked as active due to the reception of the latest 1442 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 1443 association overall error count as well (as defined in Section 8.1). 1445 --------- 1446 New text: (Section 8.3) 1447 --------- 1449 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1450 should clear the error counter of the destination transport address 1451 to which the HEARTBEAT was sent, and mark the destination transport 1452 address as active if it is not so marked. The endpoint SHOULD 1453 report to the upper layer when an inactive destination address 1454 is marked as active due to the reception of the latest 1455 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK should also clear 1456 the association overall error counter (as defined in Section 8.1). 1458 --------- 1459 Old text: (Section 9.2) 1460 --------- 1462 An endpoint should limit the number of retransmissions of the 1463 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1464 If this threshold is exceeded, the endpoint should destroy the TCB 1465 and MUST report the peer endpoint unreachable to the upper layer (and 1466 thus the association enters the CLOSED state). 1468 --------- 1469 New text: (Section 9.2) 1470 --------- 1472 An endpoint should limit the number of retransmissions of the 1473 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1474 If this threshold is exceeded, the endpoint should destroy the TCB 1475 and SHOULD report the peer endpoint unreachable to the upper layer 1476 (and thus the association enters the CLOSED state). 1478 --------- 1479 Old text: (Section 9.2) 1480 --------- 1482 The sender of the SHUTDOWN ACK should limit the number of 1483 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1484 'Association.Max.Retrans'. If this threshold is exceeded, the 1485 endpoint should destroy the TCB and may report the peer endpoint 1486 unreachable to the upper layer (and thus the association enters the 1487 CLOSED state). 1489 --------- 1490 New text: (Section 9.2) 1491 --------- 1493 The sender of the SHUTDOWN ACK should limit the number of 1494 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1495 'Association.Max.Retrans'. If this threshold is exceeded, the 1496 endpoint should destroy the TCB and SHOULD report the peer endpoint 1497 unreachable to the upper layer (and thus the association enters the 1498 CLOSED state). 1500 3.23.3. Solution Description 1502 The inconsistencies are removed by using consistently SHOULD. 1504 3.24. SACK.Delay Not Listed as a Protocol Parameter 1506 3.24.1. Description of the Problem 1508 SCTP as specified in [RFC4960] supports delaying SACKs. The timer 1509 value for this is a parameter and Section 6.2 of [RFC4960] specifies 1510 a default and maximum value for it. However, defining a name for 1511 this parameter and listing it in the table of protocol parameters in 1512 Section 15 of [RFC4960] is missing. 1514 This issue was reported as an Errata for [RFC4960] with Errata ID 1515 4656. 1517 3.24.2. Text Changes to the Document 1519 --------- 1520 Old text: (Section 6.2) 1521 --------- 1523 An implementation MUST NOT allow the maximum delay to be configured 1524 to be more than 500 ms. In other words, an implementation MAY lower 1525 this value below 500 ms but MUST NOT raise it above 500 ms. 1527 --------- 1528 New text: (Section 6.2) 1529 --------- 1531 An implementation MUST NOT allow the maximum delay (protocol 1532 parameter 'SACK.Delay') to be configured to be more than 500 ms. 1533 In other words, an implementation MAY lower the value of 1534 SACK.Delay below 500 ms but MUST NOT raise it above 500 ms. 1536 --------- 1537 Old text: (Section 15) 1538 --------- 1540 The following protocol parameters are RECOMMENDED: 1542 RTO.Initial - 3 seconds 1543 RTO.Min - 1 second 1544 RTO.Max - 60 seconds 1545 Max.Burst - 4 1546 RTO.Alpha - 1/8 1547 RTO.Beta - 1/4 1548 Valid.Cookie.Life - 60 seconds 1549 Association.Max.Retrans - 10 attempts 1550 Path.Max.Retrans - 5 attempts (per destination address) 1551 Max.Init.Retransmits - 8 attempts 1552 HB.interval - 30 seconds 1553 HB.Max.Burst - 1 1555 --------- 1556 New text: (Section 15) 1557 --------- 1559 The following protocol parameters are RECOMMENDED: 1561 RTO.Initial - 3 seconds 1562 RTO.Min - 1 second 1563 RTO.Max - 60 seconds 1564 Max.Burst - 4 1565 RTO.Alpha - 1/8 1566 RTO.Beta - 1/4 1567 Valid.Cookie.Life - 60 seconds 1568 Association.Max.Retrans - 10 attempts 1569 Path.Max.Retrans - 5 attempts (per destination address) 1570 Max.Init.Retransmits - 8 attempts 1571 HB.interval - 30 seconds 1572 HB.Max.Burst - 1 1573 SACK.Delay - 200 milliseconds 1575 3.24.3. Solution Description 1577 The parameter was given a name and added to the list of protocol 1578 parameters. 1580 3.25. Processing of Chunks in an Incoming SCTP Packet 1582 3.25.1. Description of the Problem 1584 There are a few places in [RFC4960] where the receiver of a packet 1585 must discard it while processing the chunks of the packet. It is 1586 unclear whether the receiver has to rollback state changes already 1587 performed while processing the packet or not. 1589 The intention of [RFC4960] is to process an incoming packet chunk by 1590 chunk and do not perform any prescreening of chunks in the received 1591 packet so the receiver must only discard a chunk causing discard and 1592 all further chunks. 1594 3.25.2. Text Changes to the Document 1596 --------- 1597 Old text: (Section 3.2) 1598 --------- 1600 00 - Stop processing this SCTP packet and discard it, do not 1601 process any further chunks within it. 1603 01 - Stop processing this SCTP packet and discard it, do not 1604 process any further chunks within it, and report the 1605 unrecognized chunk in an 'Unrecognized Chunk Type'. 1607 --------- 1608 New text: (Section 3.2) 1609 --------- 1611 00 - Stop processing this SCTP packet, discard the unrecognized 1612 chunk and all further chunks. 1614 01 - Stop processing this SCTP packet, discard the unrecognized 1615 chunk and all further chunks, and report the unrecognized 1616 chunk in an 'Unrecognized Chunk Type'. 1618 --------- 1619 Old text: (Section 11.3) 1620 --------- 1622 It is helpful for some firewalls if they can inspect just the first 1623 fragment of a fragmented SCTP packet and unambiguously determine 1624 whether it corresponds to an INIT chunk (for further information, 1625 please refer to [RFC1858]). Accordingly, we stress the requirements, 1626 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1627 with any other chunk in a packet, and (2) a packet containing an INIT 1628 chunk MUST have a zero Verification Tag. Furthermore, we require 1629 that the receiver of an INIT chunk MUST enforce these rules by 1630 silently discarding an arriving packet with an INIT chunk that is 1631 bundled with other chunks or has a non-zero verification tag and 1632 contains an INIT-chunk. 1634 --------- 1635 New text: (Section 11.3) 1636 --------- 1638 It is helpful for some firewalls if they can inspect just the first 1639 fragment of a fragmented SCTP packet and unambiguously determine 1640 whether it corresponds to an INIT chunk (for further information, 1641 please refer to [RFC1858]). Accordingly, we stress the requirements, 1642 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1643 with any other chunk in a packet, and (2) a packet containing an INIT 1644 chunk MUST have a zero Verification Tag. Furthermore, we require 1645 that the receiver of an INIT chunk MUST enforce these rules by 1646 silently discarding the INIT chunk and all further chunks if the INIT 1647 chunk is bundled with other chunks or the packet has a non-zero 1648 verification tag. 1650 3.25.3. Solution Description 1652 The new text makes it clear that chunks can be processed from the 1653 beginning to the end and no rollback or pre-screening is required. 1655 3.26. CWND Increase in Congestion Avoidance Phase 1657 3.26.1. Description of the Problem 1659 [RFC4960] in Section 7.2.2 prescribes to increase cwnd by 1*MTU per 1660 RTT if the sender has cwnd or more bytes of outstanding data to the 1661 corresponding address in the Congestion Avoidance phase. However, 1662 this is described without normative language. Moreover, 1663 Section 7.2.2 includes an algorithm how an implementation can achieve 1664 it but this algorithm is underspecified and actually allows 1665 increasing cwnd by more than 1*MTU per RTT. 1667 3.26.2. Text Changes to the Document 1669 --------- 1670 Old text: (Section 7.2.2) 1671 --------- 1673 When cwnd is greater than ssthresh, cwnd should be incremented by 1674 1*MTU per RTT if the sender has cwnd or more bytes of data 1675 outstanding for the corresponding transport address. 1677 --------- 1678 New text: (Section 7.2.2) 1679 --------- 1681 When cwnd is greater than ssthresh, cwnd should be incremented by 1682 1*MTU per RTT if the sender has cwnd or more bytes of data 1683 outstanding for the corresponding transport address. The basic 1684 guidelines for incrementing cwnd during congestion avoidance are: 1686 o SCTP MAY increment cwnd by 1*MTU. 1688 o SCTP SHOULD increment cwnd by one 1*MTU once per RTT when 1689 the sender has cwnd or more bytes of data outstanding for 1690 the corresponding transport address. 1692 o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT. 1694 --------- 1695 Old text: (Section 7.2.2) 1696 --------- 1698 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1699 that advances the Cumulative TSN Ack Point, increase 1700 partial_bytes_acked by the total number of bytes of all new chunks 1701 acknowledged in that SACK including chunks acknowledged by the new 1702 Cumulative TSN Ack and by Gap Ack Blocks. 1704 o When partial_bytes_acked is equal to or greater than cwnd and 1705 before the arrival of the SACK the sender had cwnd or more bytes 1706 of data outstanding (i.e., before arrival of the SACK, flightsize 1707 was greater than or equal to cwnd), increase cwnd by MTU, and 1708 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 1710 --------- 1711 New text: (Section 7.2.2) 1712 --------- 1714 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1715 increase partial_bytes_acked by the total number of bytes of all 1716 new chunks acknowledged in that SACK including chunks acknowledged 1717 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1718 of bytes of duplicated chunks reported in Duplicate TSNs. 1720 o When partial_bytes_acked is greater than cwnd and before the 1721 arrival of the SACK the sender had less bytes of data outstanding 1722 than cwnd (i.e., before arrival of the SACK, flightsize was less 1723 than cwnd), reset partial_bytes_acked to cwnd. 1725 o When partial_bytes_acked is equal to or greater than cwnd and 1726 before the arrival of the SACK the sender had cwnd or more bytes 1727 of data outstanding (i.e., before arrival of the SACK, flightsize 1728 was greater than or equal to cwnd), partial_bytes_acked is reset 1729 to (partial_bytes_acked - cwnd). Next, cwnd is increased by MTU. 1731 3.26.3. Solution Description 1733 The basic guidelines for incrementing cwnd during congestion 1734 avoidance phase are added into Section 7.2.2. The guidelines include 1735 the normative language and are aligned with [RFC5681]. 1737 The algorithm from Section 7.2.2 is improved to not allow increasing 1738 cwnd by more than 1*MTU per RTT. 1740 3.27. Refresh of cwnd and ssthresh after Idle Period 1742 3.27.1. Description of the Problem 1744 [RFC4960] prescribes to adjust cwnd per RTO if the endpoint does not 1745 transmit data on a given transport address. In addition to that, it 1746 prescribes to set cwnd to the initial value after a sufficiently long 1747 idle period. The latter is excessive. Moreover, it is unclear what 1748 is a sufficiently long idle period. 1750 [RFC4960] doesn't specify the handling of ssthresh in the idle case. 1751 If ssthres is reduced due to a packet loss, ssthresh is never 1752 recovered. So traffic can end up in Congestion Avoidance all the 1753 time, resulting in a low sending rate and bad performance. The 1754 problem is even more serious for SCTP because in a multi-homed SCTP 1755 association traffic switch back to the previously failed primary path 1756 will also lead to the situation where traffic ends up in Congestion 1757 Avoidance. 1759 3.27.2. Text Changes to the Document 1761 --------- 1762 Old text: (Section 7.2.1) 1763 --------- 1765 o The initial cwnd before DATA transmission or after a sufficiently 1766 long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 1767 bytes)). 1769 --------- 1770 New text: (Section 7.2.1) 1771 --------- 1773 o The initial cwnd before DATA transmission MUST be set to 1774 min(4*MTU, max (2*MTU, 4380 bytes)). 1776 --------- 1777 Old text: (Section 7.2.1) 1778 --------- 1780 o When the endpoint does not transmit data on a given transport 1781 address, the cwnd of the transport address should be adjusted to 1782 max(cwnd/2, 4*MTU) per RTO. 1784 --------- 1785 New text: (Section 7.2.1) 1786 --------- 1787 o When the endpoint does not transmit data on a given transport 1788 address, the cwnd of the transport address should be adjusted to 1789 max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the 1790 ssthresh of the transport address should be adjusted to the cwnd. 1792 3.27.3. Solution Description 1794 A rule about cwnd adjustment after a sufficiently long idle period is 1795 removed. 1797 The text is updated to refresh ssthresh after the idle period. When 1798 the idle period is detected, the cwnd value is stored to the ssthresh 1799 value. 1801 3.28. Window Updates After Receiver Window Opens Up 1802 3.28.1. Description of the Problem 1804 The sending of SACK chunks for window updates is only indirectly 1805 referenced in [RFC4960], Section 6.2, where it is stated that an SCTP 1806 receiver must not generate more than one SACK for every incoming 1807 packet, other than to update the offered window. 1809 However, the sending of window updates when the receiver window opens 1810 up is necessary to avoid performance problems. 1812 3.28.2. Text Changes to the Document 1814 --------- 1815 Old text: (Section 6.2) 1816 --------- 1818 An SCTP receiver MUST NOT generate more than one SACK for every 1819 incoming packet, other than to update the offered window as the 1820 receiving application consumes new data. 1822 --------- 1823 New text: (Section 6.2) 1824 --------- 1826 An SCTP receiver MUST NOT generate more than one SACK for every 1827 incoming packet, other than to update the offered window as the 1828 receiving application consumes new data. When the window opens 1829 up, an SCTP receiver SHOULD send additional SACK chunks to update 1830 the window even if no new data is received. The receiver MUST avoid 1831 sending large burst of window updates. 1833 3.28.3. Solution Description 1835 The new text makes clear that additional SACK chunks for window 1836 updates should be sent as long as excessive bursts are avoided. 1838 3.29. Path of DATA and Reply Chunks 1840 3.29.1. Description of the Problem 1842 Section 6.4 of [RFC4960] describes the transmission policy for multi- 1843 homed SCTP endpoints. However, there are the following issues with 1844 it: 1846 o It states that a SACK should be sent to the source address of an 1847 incoming DATA. However, it is known that other SACK policies 1848 (e.g. sending SACKs always to the primary path) may be more 1849 beneficial in some situations. 1850 o Initially it states that an endpoint should always transmit DATA 1851 chunks to the primary path. Then it states that the rule for 1852 transmittal of reply chunks should also be followed if the 1853 endpoint is bundling DATA chunks together with the reply chunk 1854 which contradicts with the first statement to always transmit DATA 1855 chunks to the primary path. Some implementations were having 1856 problems with it and sent DATA chunks bundled with reply chunks to 1857 a different destination address than the primary path that caused 1858 many gaps. 1860 3.29.2. Text Changes to the Document 1862 --------- 1863 Old text: (Section 6.4) 1864 --------- 1866 An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, 1867 etc.) to the same destination transport address from which it 1868 received the DATA or control chunk to which it is replying. This 1869 rule should also be followed if the endpoint is bundling DATA chunks 1870 together with the reply chunk. 1872 However, when acknowledging multiple DATA chunks received in packets 1873 from different source addresses in a single SACK, the SACK chunk may 1874 be transmitted to one of the destination transport addresses from 1875 which the DATA or control chunks being acknowledged were received. 1877 --------- 1878 New text: (Section 6.4) 1879 --------- 1881 An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, 1882 HEARTBEAT ACK, etc.) in response to control chunks to the same 1883 destination transport address from which it received the control 1884 chunk to which it is replying. 1886 The selection of the destination transport address for packets containing 1887 SACK chunks is implementation dependent. However, an endpoint SHOULD NOT vary 1888 the destination transport address of a SACK when it receives DATA chunks 1889 from the same source address. 1891 When acknowledging multiple DATA chunks received in packets 1892 from different source addresses in a single SACK, the SACK chunk MAY 1893 be transmitted to one of the destination transport addresses from 1894 which the DATA or control chunks being acknowledged were received. 1896 3.29.3. Solution Description 1898 The SACK transmission policy is left implementation dependent but it 1899 is specified to not vary the destination address of a packet 1900 containing a SACK chunk unless there are reasons for it as it may 1901 negatively impact RTT measurement. 1903 A confusing statement that prescribes to follow the rule for 1904 transmittal of reply chunks when the endpoint is bundling DATA chunks 1905 together with the reply chunk is removed. 1907 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 1909 3.30.1. Description of the Problem 1911 [RFC4960] uses outstanding data, flightsize and data in flight key 1912 terms in formulas and statements but their definitions are not 1913 provided in Section 1.3. Furthermore, outstanding data does not 1914 include DATA chunks which are classified as lost but which has not 1915 been retransmitted yet and there is a paragraph in Section 6.1 of 1916 [RFC4960] where this statement is broken. 1918 3.30.2. Text Changes to the Document 1920 --------- 1921 Old text: (Section 1.3) 1922 --------- 1924 o Congestion window (cwnd): An SCTP variable that limits the data, 1925 in number of bytes, a sender can send to a particular destination 1926 transport address before receiving an acknowledgement. 1928 ... 1930 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 1931 DATA chunk) that has been sent by the endpoint but for which it 1932 has not yet received an acknowledgement. 1934 --------- 1935 New text: (Section 1.3) 1936 --------- 1938 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 1939 DATA chunk) that has been sent by the endpoint but for which it 1940 has not yet received an acknowledgement. 1942 o Outstanding data (or Data outstanding or Data in flight): The 1943 total amount of the DATA chunks associated with outstanding TSNs. 1945 A retransmitted DATA chunk is counted once in outstanding data. 1946 A DATA chunk which is classified as lost but which has not been 1947 retransmitted yet is not in outstanding data. 1949 o Flightsize: The amount of bytes of outstanding data to a 1950 particular destination transport address at any given time. 1952 o Congestion window (cwnd): An SCTP variable that limits outstanding 1953 data, in number of bytes, a sender can send to a particular 1954 destination transport address before receiving an acknowledgement. 1956 --------- 1957 Old text: (Section 6.1) 1958 --------- 1960 C) When the time comes for the sender to transmit, before sending new 1961 DATA chunks, the sender MUST first transmit any outstanding DATA 1962 chunks that are marked for retransmission (limited by the current 1963 cwnd). 1965 --------- 1966 New text: (Section 6.1) 1967 --------- 1969 C) When the time comes for the sender to transmit, before sending new 1970 DATA chunks, the sender MUST first transmit any DATA chunks that 1971 are marked for retransmission (limited by the current cwnd). 1973 3.30.3. Solution Description 1975 Now Section 1.3, Key Terms, includes explanations of outstanding 1976 data, data in flight and flightsize key terms. Section 6.1 is 1977 corrected to properly use the outstanding data term. 1979 3.31. CWND Degradation due to Max.Burst 1981 3.31.1. Description of the Problem 1983 Some implementations were experiencing a degradation of cwnd because 1984 of the Max.Burst limit. This was due to misinterpretation of the 1985 suggestion in [RFC4960], Section 6.1, on how to use the Max.Burst 1986 parameter when calculating the number of packets to transmit. 1988 3.31.2. Text Changes to the Document 1989 --------- 1990 Old text: (Section 6.1) 1991 --------- 1993 D) When the time comes for the sender to transmit new DATA chunks, 1994 the protocol parameter Max.Burst SHOULD be used to limit the 1995 number of packets sent. The limit MAY be applied by adjusting 1996 cwnd as follows: 1998 if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + 1999 Max.Burst*MTU 2001 Or it MAY be applied by strictly limiting the number of packets 2002 emitted by the output routine. 2004 --------- 2005 New text: (Section 6.1) 2006 --------- 2008 D) When the time comes for the sender to transmit new DATA chunks, 2009 the protocol parameter Max.Burst SHOULD be used to limit the 2010 number of packets sent. The limit MAY be applied by adjusting 2011 cwnd as follows: 2013 if((flightsize + Max.Burst*MTU) < cwnd) 2014 cwnd = flightsize + Max.Burst*MTU 2016 Or it MAY be applied by strictly limiting the number of packets 2017 emitted by the output routine. When calculating the number of 2018 packets to transmit and particularly using the formula above, 2019 cwnd SHOULD NOT be changed. 2021 3.31.3. Solution Description 2023 The new text clarifies that cwnd should not be changed when appling 2024 the Max.Burst limit. This mitigates packet bursts related to the 2025 reception of SACK chunks, but not bursts related to an application 2026 sending a burst of user messages. 2028 3.32. Reduction of RTO.Initial 2030 3.32.1. Description of the Problem 2032 [RFC4960] uses 3 seconds as the default value for RTO.Initial in 2033 accordance with Section 4.3.2.1 of [RFC1122]. [RFC6298] updates 2034 [RFC1122] and lowers the initial value of the retransmission timer 2035 from 3 seconds to 1 second. 2037 3.32.2. Text Changes to the Document 2039 --------- 2040 Old text: (Section 15) 2041 --------- 2043 The following protocol parameters are RECOMMENDED: 2045 RTO.Initial - 3 seconds 2046 RTO.Min - 1 second 2047 RTO.Max - 60 seconds 2048 Max.Burst - 4 2049 RTO.Alpha - 1/8 2050 RTO.Beta - 1/4 2051 Valid.Cookie.Life - 60 seconds 2052 Association.Max.Retrans - 10 attempts 2053 Path.Max.Retrans - 5 attempts (per destination address) 2054 Max.Init.Retransmits - 8 attempts 2055 HB.interval - 30 seconds 2056 HB.Max.Burst - 1 2057 SACK.Delay - 200 milliseconds 2059 --------- 2060 New text: (Section 15) 2061 --------- 2063 The following protocol parameters are RECOMMENDED: 2065 RTO.Initial - 1 second 2066 RTO.Min - 1 second 2067 RTO.Max - 60 seconds 2068 Max.Burst - 4 2069 RTO.Alpha - 1/8 2070 RTO.Beta - 1/4 2071 Valid.Cookie.Life - 60 seconds 2072 Association.Max.Retrans - 10 attempts 2073 Path.Max.Retrans - 5 attempts (per destination address) 2074 Max.Init.Retransmits - 8 attempts 2075 HB.interval - 30 seconds 2076 HB.Max.Burst - 1 2077 SACK.Delay - 200 milliseconds 2079 3.32.3. Solution Description 2081 The value RTO.Initial has been lowered to 1 second to be in tune with 2082 [RFC6298]. 2084 3.33. Ordering of Bundled SACK and ERROR Chunks 2086 3.33.1. Description of the Problem 2088 When an SCTP endpoint receives a DATA chunk with an invalid stream 2089 identifier it shall acknowledge it by sending a SACK chunk and 2090 indicate that the stream identifier was invalid by sending an ERROR 2091 chunk. These two chunks may be bundled. However, [RFC4960] requires 2092 in case of bundling that the ERROR chunk follows the SACK chunk. 2093 This restriction of the ordering is not necessary and might only 2094 limit interoperability. 2096 3.33.2. Text Changes to the Document 2098 --------- 2099 Old text: (Section 6.5) 2100 --------- 2102 Every DATA chunk MUST carry a valid stream identifier. If an 2103 endpoint receives a DATA chunk with an invalid stream identifier, it 2104 shall acknowledge the reception of the DATA chunk following the 2105 normal procedure, immediately send an ERROR chunk with cause set to 2106 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2107 DATA chunk. The endpoint may bundle the ERROR chunk in the same 2108 packet as the SACK as long as the ERROR follows the SACK. 2110 --------- 2111 New text: (Section 6.5) 2112 --------- 2114 Every DATA chunk MUST carry a valid stream identifier. If an 2115 endpoint receives a DATA chunk with an invalid stream identifier, it 2116 shall acknowledge the reception of the DATA chunk following the 2117 normal procedure, immediately send an ERROR chunk with cause set to 2118 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2119 DATA chunk. The endpoint may bundle the ERROR chunk and the SACK Chunk 2120 in the same packet. 2122 3.33.3. Solution Description 2124 The unnecessary restriction regarding the ordering of the SACK and 2125 ERROR chunk has been removed. 2127 3.34. Undefined Parameter Returned by RECEIVE Primitive 2128 3.34.1. Description of the Problem 2130 [RFC4960] provides a description of an abstract API. In the 2131 definition of the RECEIVE primitive an optional parameter with name 2132 "delivery number" is mentioned. However, no definition of this 2133 parameter is given in [RFC4960] and the parameter is unnecessary. 2135 3.34.2. Text Changes to the Document 2137 --------- 2138 Old text: (Section 10.1) 2139 --------- 2141 G) Receive 2143 Format: RECEIVE(association id, buffer address, buffer size 2144 [,stream id]) 2145 -> byte count [,transport address] [,stream id] [,stream sequence 2146 number] [,partial flag] [,delivery number] [,payload protocol-id] 2148 --------- 2149 New text: (Section 10.1) 2150 --------- 2152 G) Receive 2154 Format: RECEIVE(association id, buffer address, buffer size 2155 [,stream id]) 2156 -> byte count [,transport address] [,stream id] [,stream sequence 2157 number] [,partial flag] [,payload protocol-id] 2159 3.34.3. Solution Description 2161 The undefined parameter has been removed. 2163 3.35. DSCP Changes 2165 3.35.1. Description of the Problem 2167 The upper layer can change the Differentiated Services Code Point 2168 (DSCP) used for packets being sent. A change of the DSCP can result 2169 in packets hitting different queues on the path and therefore the 2170 congestion control should be initialized when the DSCP is changed by 2171 the upper layer. This is not described in [RFC4960]. 2173 3.35.2. Text Changes to the Document 2175 --------- 2176 New text: (Section 7.2.5) 2177 --------- 2179 SCTP implementations MAY allow an application to configure the 2180 Differentiated Services Code Point (DSCP) used for sending packets. 2181 If a DSCP change might result in outgoing packets being queued in different 2182 queues, the congestion control parameters for all affected destination 2183 addresses MUST be reset to their initial values. 2185 --------- 2186 Old text: (Section 10.1) 2187 --------- 2189 M) Set Protocol Parameters 2191 Format: SETPROTOCOLPARAMETERS(association id, 2192 [,destination transport address,] 2193 protocol parameter list) 2194 -> result 2196 This primitive allows the local SCTP to customize the protocol 2197 parameters. 2199 Mandatory attributes: 2201 o association id - local handle to the SCTP association. 2203 o protocol parameter list - the specific names and values of the 2204 protocol parameters (e.g., Association.Max.Retrans; see Section 2205 15) that the SCTP user wishes to customize. 2207 --------- 2208 Old text: (Section 10.1) 2209 --------- 2211 M) Set Protocol Parameters 2213 Format: SETPROTOCOLPARAMETERS(association id, 2214 [,destination transport address,] 2215 protocol parameter list) 2216 -> result 2218 This primitive allows the local SCTP to customize the protocol 2219 parameters. 2221 Mandatory attributes: 2223 o association id - local handle to the SCTP association. 2225 o protocol parameter list - the specific names and values of the 2226 protocol parameters (e.g., Association.Max.Retrans; see Section 2227 15, or other parameters like the DSCP) that the SCTP user wishes 2228 to customize. 2230 3.35.3. Solution Description 2232 Text describing the required action on DSCP changes has been added. 2234 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages 2236 3.36.1. Description of the Problem 2238 Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 2239 messages. The text explicitly describes the handling of ICMPv6 2240 packets indicating reachability problems, but does not do the same 2241 for the corresponding ICMPv4 packets. 2243 3.36.2. Text Changes to the Document 2245 --------- 2246 Old text: (Appendix C) 2247 --------- 2249 ICMP1) An implementation MAY ignore all ICMPv4 messages where the 2250 type field is not set to "Destination Unreachable". 2252 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 2253 type field is not "Destination Unreachable", "Parameter 2254 Problem",, or "Packet Too Big". 2256 ICMP3) An implementation MAY ignore any ICMPv4 messages where the 2257 code does not indicate "Protocol Unreachable" or 2258 "Fragmentation Needed". 2260 ICMP4) An implementation MAY ignore all ICMPv6 messages of type 2261 "Parameter Problem" if the code is not "Unrecognized Next 2262 Header Type Encountered". 2264 ICMP5) An implementation MUST use the payload of the ICMP message (v4 2265 or v6) to locate the association that sent the message to 2266 which ICMP is responding. If the association cannot be found, 2267 an implementation SHOULD ignore the ICMP message. 2269 ICMP6) An implementation MUST validate that the Verification Tag 2270 contained in the ICMP message matches the Verification Tag of 2271 the peer. If the Verification Tag is not 0 and does NOT 2272 match, discard the ICMP message. If it is 0 and the ICMP 2273 message contains enough bytes to verify that the chunk type is 2274 an INIT chunk and that the Initiate Tag matches the tag of the 2275 peer, continue with ICMP7. If the ICMP message is too short 2276 or the chunk type or the Initiate Tag does not match, silently 2277 discard the packet. 2279 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 2280 "Fragmentation Needed", an implementation MAY process this 2281 information as defined for PATH MTU discovery. 2283 ICMP8) If the ICMP code is an "Unrecognized Next Header Type 2284 Encountered" or a "Protocol Unreachable", an implementation 2285 MUST treat this message as an abort with the T bit set if it 2286 does not contain an INIT chunk. If it does contain an INIT 2287 chunk and the association is in the COOKIE-WAIT state, handle 2288 the ICMP message like an ABORT. 2290 ICMP9) If the ICMPv6 code is "Destination Unreachable", the 2291 implementation MAY mark the destination into the unreachable 2292 state or alternatively increment the path error counter. 2294 --------- 2295 New text: (Appendix C) 2296 --------- 2298 ICMP1) An implementation MAY ignore all ICMPv4 messages where the 2299 type field is not set to "Destination Unreachable". 2301 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 2302 type field is not "Destination Unreachable", "Parameter 2303 Problem",, or "Packet Too Big". 2305 ICMP3) An implementation MAY ignore all ICMPv6 messages of type 2306 "Parameter Problem" if the code is not "Unrecognized Next 2307 Header Type Encountered". 2309 ICMP4) An implementation MUST use the payload of the ICMP message (v4 2310 or v6) to locate the association that sent the message to 2311 which ICMP is responding. If the association cannot be found, 2312 an implementation SHOULD ignore the ICMP message. 2314 ICMP5) An implementation MUST validate that the Verification Tag 2315 contained in the ICMP message matches the Verification Tag of 2316 the peer. If the Verification Tag is not 0 and does NOT 2317 match, discard the ICMP message. If it is 0 and the ICMP 2318 message contains enough bytes to verify that the chunk type is 2319 an INIT chunk and that the Initiate Tag matches the tag of the 2320 peer, continue with ICMP7. If the ICMP message is too short 2321 or the chunk type or the Initiate Tag does not match, silently 2322 discard the packet. 2324 ICMP6) If the ICMP message is either a v6 "Packet Too Big" or a v4 2325 "Fragmentation Needed", an implementation MAY process this 2326 information as defined for PATH MTU discovery. 2328 ICMP7) If the ICMP code is an "Unrecognized Next Header Type 2329 Encountered" or a "Protocol Unreachable", an implementation 2330 MUST treat this message as an abort with the T bit set if it 2331 does not contain an INIT chunk. If it does contain an INIT 2332 chunk and the association is in the COOKIE-WAIT state, handle 2333 the ICMP message like an ABORT. 2335 ICMP8) If the ICMP code is "Destination Unreachable", the 2336 implementation MAY mark the destination into the unreachable 2337 state or alternatively increment the path error counter. 2339 3.36.3. Solution Description 2341 The text has been changed to not limit the processing of ICMPv4 2342 packets with type "Destination Unreachable" by removing the third 2343 rule. Furthermore, remove in the ninth rule the limitation to 2344 ICMPv6. 2346 3.37. Handling of Soft Errors 2348 3.37.1. Description of the Problem 2350 [RFC1122] defines the handling of soft errors and hard errors for 2351 TCP. Appendix C of [RFC4960] only deals with hard errors. 2353 3.37.2. Text Changes to the Document 2354 --------- 2355 Old text: (Appendix C) 2356 --------- 2358 ICMP8) If the ICMP code is "Destination Unreachable", the 2359 implementation MAY mark the destination into the unreachable 2360 state or alternatively increment the path error counter. 2362 --------- 2363 New text: (Appendix C) 2364 --------- 2366 ICMP8) If the ICMP code is "Destination Unreachable", the 2367 implementation MAY mark the destination into the unreachable 2368 state or alternatively increment the path error counter. 2369 SCTP MAY provide information to the upper layer indicating the reception 2370 of ICMP messages when reporting a network status change. 2372 3.37.3. Solution Description 2374 Text has been added allowing the SCTP to notify the application in 2375 case of soft errors. 2377 3.38. Honoring CWND 2379 3.38.1. Description of the Problem 2381 When using the slow start algorithm, SCTP increases the congestion 2382 window only when it is being fully utilized. Since SCTP uses DATA 2383 chunks and does not use the congestion window to fragment user 2384 messages, this requires that some overbooking of the congestion 2385 window is allowed. 2387 3.38.2. Text Changes to the Document 2388 --------- 2389 Old text: (Section 6.1) 2390 --------- 2392 B) At any given time, the sender MUST NOT transmit new data to a 2393 given transport address if it has cwnd or more bytes of data 2394 outstanding to that transport address. 2396 --------- 2397 New text: (Section 6.1) 2398 --------- 2400 B) At any given time, the sender MUST NOT transmit new data to a 2401 given transport address if it has cwnd + (PMTU - 1) or more bytes of data 2402 outstanding to that transport address. If data is available the 2403 sender SHOULD exceed cwnd by up to (PMTU-1) bytes on a new data 2404 transmission if the flightsize does not currently reach cwnd. 2405 The breach of cwnd MUST constitute one packet only. 2407 --------- 2408 Old text: (Section 7.2.1) 2409 --------- 2411 o Whenever cwnd is greater than zero, the endpoint is allowed to 2412 have cwnd bytes of data outstanding on that transport address. 2414 --------- 2415 New text: (Section 7.2.1) 2416 --------- 2417 o Whenever cwnd is greater than zero, the endpoint is allowed to 2418 have cwnd bytes of data outstanding on that transport address. 2419 A limited overbooking as described in B) of Section 6.1 should 2420 be supported. 2422 3.38.3. Solution Description 2424 Text was added that to clarify how the CWND limit should be handled. 2426 3.39. Zero Window Probing 2428 3.39.1. Description of the Problem 2430 The text describing zero window probing was not clearly handling the 2431 case where the window was not zero, but too small for the next DATA 2432 chunk to be transmitted. Even in this case, zero window probing has 2433 to be performed to avoid deadlocks. 2435 3.39.2. Text Changes to the Document 2437 --------- 2438 Old text: (Section 6.1) 2439 --------- 2441 A) At any given time, the data sender MUST NOT transmit new data to 2442 any destination transport address if its peer's rwnd indicates 2443 that the peer has no buffer space (i.e., rwnd is 0; see Section 2444 6.2.1). However, regardless of the value of rwnd (including if it 2445 is 0), the data sender can always have one DATA chunk in flight to 2446 the receiver if allowed by cwnd (see rule B, below). This rule 2447 allows the sender to probe for a change in rwnd that the sender 2448 missed due to the SACK's having been lost in transit from the data 2449 receiver to the data sender. 2451 When the receiver's advertised window is zero, this probe is 2452 called a zero window probe. Note that a zero window probe SHOULD 2453 only be sent when all outstanding DATA chunks have been 2454 cumulatively acknowledged and no DATA chunks are in flight. Zero 2455 window probing MUST be supported. 2457 --------- 2458 New text: (Section 6.1) 2459 --------- 2461 A) At any given time, the data sender MUST NOT transmit new data to 2462 any destination transport address if its peer's rwnd indicates 2463 that the peer has no buffer space (i.e., rwnd is smaller than the 2464 size of the next DATA chunk; see Section 6.2.1). 2465 However, regardless of the value of rwnd (including if it is 0), 2466 the data sender can always have one DATA chunk in flight to 2467 the receiver if allowed by cwnd (see rule B, below). This rule 2468 allows the sender to probe for a change in rwnd that the sender 2469 missed due to the SACK's having been lost in transit from the data 2470 receiver to the data sender. 2472 When the receiver has no buffer space, this probe is 2473 called a zero window probe. Note that a zero window probe SHOULD 2474 only be sent when all outstanding DATA chunks have been 2475 cumulatively acknowledged and no DATA chunks are in flight. Zero 2476 window probing MUST be supported. 2478 3.39.3. Solution Description 2480 The terminology is used in a cleaner way. 2482 4. IANA Considerations 2484 This document does not require any actions from IANA. 2486 5. Security Considerations 2488 This document does not add any security considerations to those given 2489 in [RFC4960]. 2491 6. Acknowledgments 2493 The authors wish to thank Pontus Andersson, Eric W. Biederman, 2494 Cedric Bonnet, Lionel Morand, Jeff Morriss, Karen E. E. Nielsen, 2495 Tom Petch, Julien Pourtet, and Michael Welzl for their invaluable 2496 comments. 2498 7. References 2500 7.1. Normative References 2502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2503 Requirement Levels", BCP 14, RFC 2119, 2504 DOI 10.17487/RFC2119, March 1997, 2505 . 2507 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 2508 RFC 4960, DOI 10.17487/RFC4960, September 2007, 2509 . 2511 7.2. Informative References 2513 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2514 Communication Layers", STD 3, RFC 1122, 2515 DOI 10.17487/RFC1122, October 1989, 2516 . 2518 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 2519 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 2520 Zhang, L., and V. Paxson, "Stream Control Transmission 2521 Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, 2522 . 2524 [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and 2525 M. Tuexen, "Stream Control Transmission Protocol (SCTP) 2526 Specification Errata and Issues", RFC 4460, 2527 DOI 10.17487/RFC4460, April 2006, 2528 . 2530 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 2531 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 2532 . 2534 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 2535 "Computing TCP's Retransmission Timer", RFC 6298, 2536 DOI 10.17487/RFC6298, June 2011, 2537 . 2539 Authors' Addresses 2541 Randall R. Stewart 2542 Netflix, Inc. 2543 Chapin, SC 29036 2544 United States 2546 Email: randall@lakerest.net 2548 Michael Tuexen 2549 Muenster University of Applied Sciences 2550 Stegerwaldstrasse 39 2551 48565 Steinfurt 2552 Germany 2554 Email: tuexen@fh-muenster.de 2556 Maksim Proshin 2557 Ericsson 2558 Kistavaegen 25 2559 Stockholm 164 80 2560 Sweden 2562 Email: mproshin@tieto.mera.ru