Tech-invite   3GPPspecs   RFCs   Search in Tech-invite

868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100IETF‑orgGroupsStats
in Index   Prev   Next

RFC 8540

Stream Control Transmission Protocol: Errata and Issues in RFC 4960

Pages: 94
Group: TSVWG
Informational
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