RFC 8540
Stream Control Transmission Protocol: Errata and Issues in RFC 4960
3.9. Miscellaneous Typos
3.9.1. Description of the Problem
While processing [RFC4960], some typos were not caught. One typo was reported as an errata for [RFC4960] with Errata ID 5003.3.9.2. Text Changes to the Document
--------- Old text: (Section 1.6) --------- Transmission Sequence Numbers wrap around when they reach 2**32 - 1. That is, the next TSN a DATA chunk MUST use after transmitting TSN = 2*32 - 1 is TSN = 0.
--------- New text: (Section 1.6) --------- Transmission Sequence Numbers wrap around when they reach 2**32 - 1. That is, the next TSN a DATA chunk MUST use after transmitting TSN = 2**32 - 1 is TSN = 0. This text is in final form and is not further updated in this document. --------- Old text: (Section 3.3.10.9) --------- No User Data: This error cause is returned to the originator of a DATA chunk if a received DATA chunk has no user data. --------- New text: (Section 3.3.10.9) --------- No User Data: This error cause is returned to the originator of a DATA chunk if a received DATA chunk has no user data. This text is in final form and is not further updated in this document. --------- Old text: (Section 6.7, Figure 9) --------- Endpoint A Endpoint Z {App sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ---------- -----> (ack delayed) (Start T3-rtx timer) DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, immediately send ack) /----- SACK [TSN Ack=6,Block=1, / Start=2,End=2] <-----/ (remove 6 from out-queue, and mark 7 as "1" missing report)
--------- New text: (Section 6.7, Figure 9) --------- Endpoint A Endpoint Z {App sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed) (Start T3-rtx timer) DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, immediately send ack) /----- SACK [TSN Ack=6,Block=1, / Start=2,End=2] <-----/ (remove 6 from out-queue, and mark 7 as "1" missing report) This text is in final form and is not further updated in this document. --------- Old text: (Section 6.10) --------- An endpoint bundles chunks by simply including multiple chunks in one outbound SCTP packet. The total size of the resultant IP datagram, including the SCTP packet and IP headers, MUST be less that or equal to the current Path MTU. --------- New text: (Section 6.10) --------- An endpoint bundles chunks by simply including multiple chunks in one outbound SCTP packet. The total size of the resultant IP datagram, including the SCTP packet and IP headers, MUST be less than or equal to the current Path MTU (PMTU). This text is in final form and is not further updated in this document.
--------- Old text: (Section 10.1 O)) --------- o Receive Unacknowledged Message Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size, [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id]) --------- New text: (Section 10.1 O)) --------- O) Receive Unacknowledged Message Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size [,stream id] [,stream sequence number] [,partial flag] [,payload protocol-id]) This text is in final form and is not further updated in this document. --------- Old text: (Section 10.1 M)) --------- M) Set Protocol Parameters Format: SETPROTOCOLPARAMETERS(association id, [,destination transport address,] protocol parameter list) --------- New text: (Section 10.1 M)) --------- M) Set Protocol Parameters Format: SETPROTOCOLPARAMETERS(association id, [destination transport address,] protocol parameter list) This text is in final form and is not further updated in this document.
--------- Old text: (Appendix C) --------- ICMP2) An implementation MAY ignore all ICMPv6 messages where the type field is not "Destination Unreachable", "Parameter Problem",, or "Packet Too Big". --------- New text: (Appendix C) --------- ICMP2) An implementation MAY ignore all ICMPv6 messages where the type field is not "Destination Unreachable", "Parameter Problem", or "Packet Too Big". This text is in final form and is not further updated in this document. --------- Old text: (Appendix C) --------- ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 "Fragmentation Needed", an implementation MAY process this information as defined for PATH MTU discovery. --------- New text: (Appendix C) --------- ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 "Fragmentation Needed", an implementation MAY process this information as defined for PMTU discovery. This text is in final form and is not further updated in this document. --------- Old text: (Section 5.4) --------- 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address is the one to which the INIT-ACK was sent.
--------- New text: (Section 5.4) --------- 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address is the address to which the INIT ACK was sent. This text is in final form and is not further updated in this document. --------- Old text: (Section 5.1.6, Figure 4) --------- COOKIE ECHO [Cookie_Z] ------\ (Start T1-init timer) \ (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED state) /---- COOKIE-ACK / (Cancel T1-init timer, <-----/ Enter ESTABLISHED state) --------- New text: (Section 5.1.6, Figure 4) --------- COOKIE ECHO [Cookie_Z] ------\ (Start T1-cookie timer) \ (Enter COOKIE-ECHOED state) \---> (build TCB, enter ESTABLISHED state) /---- COOKIE ACK / (Cancel T1-cookie timer, <---/ enter ESTABLISHED state) This text has been modified by multiple errata. It includes modifications from Section 3.8. It is in final form and is not further updated in this document. --------- Old text: (Section 5.2.5) --------- 5.2.5. Handle Duplicate COOKIE-ACK.
--------- New text: (Section 5.2.5) --------- 5.2.5. Handle Duplicate COOKIE ACK. This text is in final form and is not further updated in this document. --------- Old text: (Section 8.3) --------- By default, an SCTP endpoint SHOULD monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). HEARTBEAT sending MAY begin upon reaching the ESTABLISHED state and is discontinued after sending either SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state (INIT sender) or the ESTABLISHED state (INIT receiver), up until reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- ACK-SENT state (SHUTDOWN receiver). --------- New text: (Section 8.3) --------- By default, an SCTP endpoint SHOULD monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). HEARTBEAT sending MAY begin upon reaching the ESTABLISHED state and is discontinued after sending either SHUTDOWN or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state (INIT sender) or the ESTABLISHED state (INIT receiver), up until reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-ACK-SENT state (SHUTDOWN receiver). This text is in final form and is not further updated in this document.3.9.3. Solution Description
Several typos have been fixed.
3.10. CRC32c Sample Code
3.10.1. Description of the Problem
The CRC32c computation is described in Appendix B of [RFC4960]. However, the corresponding sample code and its explanation appear at the end of Appendix C of [RFC4960], which deals with ICMP handling.3.10.2. Text Changes to the Document
The text in Appendix C of [RFC4960], starting with the following sentence, needs to be moved to the end of Appendix B. The following non-normative sample code is taken from an open-source CRC generator [WILLIAMS93], using the "mirroring" technique and yielding a lookup table for SCTP CRC32c with 256 entries, each 32 bits wide. This text has been modified by multiple errata. It includes modifications from Section 3.5. It is further updated in Section 3.46.3.10.3. Solution Description
The text is moved to the appropriate location.3.11. partial_bytes_acked after T3-rtx Expiration
3.11.1. Description of the Problem
Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked should be reset to 0 after packet loss detection from selective acknowledgment (SACK), but this information is not accounted for in the case of T3-rtx timer expiration.3.11.2. Text Changes to the Document
--------- Old text: (Section 7.2.3) --------- When the T3-rtx timer expires on an address, SCTP should perform slow start by: ssthresh = max(cwnd/2, 4*MTU) cwnd = 1*MTU
--------- New text: (Section 7.2.3) --------- When the T3-rtx timer expires on an address, SCTP SHOULD perform slow start by: ssthresh = max(cwnd/2, 4*MTU) cwnd = 1*MTU partial_bytes_acked = 0 This text is in final form and is not further updated in this document.3.11.3. Solution Description
The new text specifies that partial_bytes_acked should be reset to 0 after T3-rtx timer expiration.3.12. Order of Adjustments of partial_bytes_acked and cwnd
3.12.1. Description of the Problem
Section 7.2.2 of [RFC4960] likely implies the wrong order of adjustments applied to partial_bytes_acked and cwnd in the congestion avoidance phase.3.12.2. Text Changes to the Document
--------- Old text: (Section 7.2.2) --------- o When partial_bytes_acked is equal to or greater than cwnd and before the arrival of the SACK the sender had cwnd or more bytes of data outstanding (i.e., before arrival of the SACK, flightsize was greater than or equal to cwnd), increase cwnd by MTU, and reset partial_bytes_acked to (partial_bytes_acked - cwnd). --------- New text: (Section 7.2.2) --------- o (1) when partial_bytes_acked is equal to or greater than cwnd and (2) before the arrival of the SACK the sender had cwnd or more bytes of data outstanding (i.e., before the arrival of the SACK,
flightsize was greater than or equal to cwnd), partial_bytes_acked
is reset to (partial_bytes_acked - cwnd). Next, cwnd is increased
by 1*MTU.
This text has been modified by multiple errata. It is further
updated in Section 3.26.
3.12.3. Solution Description
The new text defines the exact order of adjustments of
partial_bytes_acked and cwnd in the congestion avoidance phase.
3.13. HEARTBEAT ACK and the Association Error Counter
3.13.1. Description of the Problem
Sections 8.1 and 8.3 of [RFC4960] prescribe that the receiver of a
HEARTBEAT ACK must reset the association overall error count. In
some circumstances, e.g., when a router discards DATA chunks but not
HEARTBEAT chunks due to the larger size of the DATA chunk, it might
be better to not clear the association error counter on reception of
the HEARTBEAT ACK and reset it only on reception of the SACK to avoid
stalling the association.
3.13.2. Text Changes to the Document
---------
Old text: (Section 8.1)
---------
The counter shall be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT
ACK is received from the peer endpoint.
---------
New text: (Section 8.1)
---------
The counter MUST be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK). When a
HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD
also be reset. The receiver of the HEARTBEAT ACK MAY choose not to
clear the counter if there is outstanding data on the association.
This allows for handling the possible difference in reachability
based on DATA chunks and HEARTBEAT chunks.
This text is in final form and is not further updated in this
document.
--------- Old text: (Section 8.3) --------- Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT should clear the error counter of the destination transport address to which the HEARTBEAT was sent, and mark the destination transport address as active if it is not so marked. The endpoint may optionally report to the upper layer when an inactive destination address is marked as active due to the reception of the latest HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the association overall error count as well (as defined in Section 8.1). --------- New text: (Section 8.3) --------- Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT MUST clear the error counter of the destination transport address to which the HEARTBEAT was sent and mark the destination transport address as active if it is not so marked. The endpoint MAY optionally report to the upper layer when an inactive destination address is marked as active due to the reception of the latest HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear the association overall error count (as defined in Section 8.1). This text has been modified by multiple errata. It is further updated in Section 3.23.3.13.3. Solution Description
The new text provides the possibility of not resetting the association overall error count when a HEARTBEAT ACK is received if there are valid reasons for not doing so.3.14. Path for Fast Retransmission
3.14.1. Description of the Problem
[RFC4960] clearly describes where to retransmit data that is timed out when the peer is multi-homed, but the same is not stated for fast retransmissions.
3.14.2. Text Changes to the Document
--------- Old text: (Section 6.4) --------- Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk that timed out to an active destination transport address that is different from the last destination address to which the DATA chunk was sent. --------- New text: (Section 6.4) --------- Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk that timed out to an active destination transport address that is different from the last destination address to which the DATA chunk was sent. When its peer is multi-homed, an endpoint SHOULD send fast retransmissions to the same destination transport address to which the original data was sent. If the primary path has been changed and the original data was sent to the old primary path before the Fast Retransmit, the implementation MAY send it to the new primary path. This text is in final form and is not further updated in this document.3.14.3. Solution Description
The new text clarifies where to send fast retransmissions.3.15. Transmittal in Fast Recovery
3.15.1. Description of the Problem
The Fast Retransmit on Gap Reports algorithm intends that only the very first packet may be sent regardless of cwnd in the Fast Recovery phase, but rule 3) in Section 7.2.4 of [RFC4960] misses this clarification.
3.15.2. Text Changes to the Document
--------- Old text: (Section 7.2.4) --------- 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the path MTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet. When a Fast Retransmit is being performed, the sender SHOULD ignore the value of cwnd and SHOULD NOT delay retransmission for this single packet. --------- New text: (Section 7.2.4) --------- 3) If not in Fast Recovery, determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the PMTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet. When a Fast Retransmit is being performed, the sender SHOULD ignore the value of cwnd and SHOULD NOT delay retransmission for this single packet. This text is in final form and is not further updated in this document.3.15.3. Solution Description
The new text explicitly specifies that only the first packet in the Fast Recovery phase be sent and that the cwnd limitations be disregarded.3.16. Initial Value of ssthresh
3.16.1. Description of the Problem
The initial value of ssthresh should be set arbitrarily high. Using the advertised receiver window of the peer is inappropriate if the peer increases its window after the handshake. Furthermore, a higher requirement level needs to be used, since not following the advice may result in performance problems.
3.16.2. Text Changes to the Document
--------- Old text: (Section 7.2.1) --------- o The initial value of ssthresh MAY be arbitrarily high (for example, implementations MAY use the size of the receiver advertised window). --------- New text: (Section 7.2.1) --------- o The initial value of ssthresh SHOULD be arbitrarily high (e.g., the size of the largest possible advertised window). This text is in final form and is not further updated in this document.3.16.3. Solution Description
The same value as the value suggested in [RFC5681], Section 3.1, is now used as an appropriate initial value. Also, the same requirement level is used.3.17. Automatically CONFIRMED Addresses
3.17.1. Description of the Problem
The Path Verification procedure of [RFC4960] prescribes that any address passed to the sender of the INIT by its upper layer be automatically CONFIRMED. This, however, is unclear if (1) only addresses in the request to initiate association establishment or (2) any addresses provided by the upper layer in any requests (e.g., in 'Set Primary') are considered.3.17.2. Text Changes to the Document
--------- Old text: (Section 5.4) --------- 1) Any address passed to the sender of the INIT by its upper layer is automatically considered to be CONFIRMED.
--------- New text: (Section 5.4) --------- 1) Any addresses passed to the sender of the INIT by its upper layer in the request to initialize an association are automatically considered to be CONFIRMED. This text is in final form and is not further updated in this document.3.17.3. Solution Description
The new text clarifies that only addresses provided by the upper layer in the request to initialize an association are automatically CONFIRMED.
(page 26 continued on part 3)
