Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8540

Stream Control Transmission Protocol: Errata and Issues in RFC 4960

Pages: 94
Obsoleted by:  9260
Part 2 of 7 – Pages 12 to 26
First   Prev   Next

Top   ToC   RFC8540 - Page 12   prevText

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.
Top   ToC   RFC8540 - Page 13
   ---------
   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)
Top   ToC   RFC8540 - Page 14
   ---------
   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.
Top   ToC   RFC8540 - Page 15
   ---------
   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.
Top   ToC   RFC8540 - Page 16
   ---------
   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.
Top   ToC   RFC8540 - Page 17
   ---------
   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.
Top   ToC   RFC8540 - Page 18
   ---------
   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.
Top   ToC   RFC8540 - Page 19

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
Top   ToC   RFC8540 - Page 20
   ---------
   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,
Top   ToC   RFC8540 - Page 21
      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.
Top   ToC   RFC8540 - Page 22
   ---------
   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.
Top   ToC   RFC8540 - Page 23

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.
Top   ToC   RFC8540 - Page 24

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.
Top   ToC   RFC8540 - Page 25

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.
Top   ToC   RFC8540 - Page 26
   ---------
   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)

Next Section