Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   None  Group: TSVWG

RFC 8540

Stream Control Transmission Protocol: Errata and Issues in RFC 4960

Pages: 94
Informational
Part 3 of 7 – Pages 26 to 41
First   Prev   Next

Top   ToC   Page 26   prevText
3.18.  Only One Packet after Retransmission Timeout

3.18.1.  Description of the Problem

   [RFC4960] is not completely clear when it describes data transmission
   after T3-rtx timer expiration.  Section 7.2.1 of [RFC4960] does not
   specify how many packets are allowed to be sent after T3-rtx timer
   expiration if more than one packet fits into cwnd.  At the same time,
   Section 7.2.3 of [RFC4960] has text without normative language saying
   that SCTP should ensure that no more than one packet will be in
   flight after T3-rtx timer expiration until successful
   acknowledgement.  The text is therefore inconsistent.

3.18.2.  Text Changes to the Document

   ---------
   Old text: (Section 7.2.1)
   ---------

   o  The initial cwnd after a retransmission timeout MUST be no more
      than 1*MTU.

   ---------
   New text: (Section 7.2.1)
   ---------

   o  The initial cwnd after a retransmission timeout MUST be no more
      than 1*MTU, and only one packet is allowed to be in flight until
      successful acknowledgement.
Top   ToC   Page 27
   This text is in final form and is not further updated in this
   document.

3.18.3.  Solution Description

   The new text clearly specifies that only one packet is allowed to be
   sent after T3-rtx timer expiration until successful acknowledgement.

3.19.  INIT ACK Path for INIT in COOKIE-WAIT State

3.19.1.  Description of the Problem

   In the case of an INIT received in the COOKIE-WAIT state, [RFC4960]
   prescribes that an INIT ACK be sent to the same destination address
   to which the original INIT has been sent.  [RFC4960] does not address
   the possibility of the upper layer providing multiple remote IP
   addresses while requesting the association establishment.  If the
   upper layer has provided multiple IP addresses and only a subset of
   these addresses are supported by the peer, then the destination
   address of the original INIT may be absent in the incoming INIT and
   sending an INIT ACK to that address is useless.

3.19.2.  Text Changes to the Document

   ---------
   Old text: (Section 5.2.1)
   ---------

   Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
   respond with an INIT ACK using the same parameters it sent in its
   original INIT chunk (including its Initiate Tag, unchanged).  When
   responding, the endpoint MUST send the INIT ACK back to the same
   address that the original INIT (sent by this endpoint) was sent.

   ---------
   New text: (Section 5.2.1)
   ---------

   Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
   respond with an INIT ACK using the same parameters it sent in its
   original INIT chunk (including its Initiate Tag, unchanged).  When
   responding, the following rules MUST be applied:

   1)  The INIT ACK MUST only be sent to an address passed by the upper
       layer in the request to initialize the association.

   2)  The INIT ACK MUST only be sent to an address reported in the
       incoming INIT.
Top   ToC   Page 28
   3)  The INIT ACK SHOULD be sent to the source address of the received
       INIT.

   This text is in final form and is not further updated in this
   document.

3.19.3.  Solution Description

   The new text requires sending an INIT ACK to a destination address
   that is passed by the upper layer and reported in the incoming INIT.
   If the source address of the INIT meets these conditions, sending the
   INIT ACK to the source address of the INIT is the preferred behavior.

3.20.  Zero Window Probing and Unreachable Primary Path

3.20.1.  Description of the Problem

   Section 6.1 of [RFC4960] states that when sending zero window probes,
   SCTP should neither increment the association counter nor increment
   the destination address error counter if it continues to receive new
   packets from the peer.  However, the reception of new packets from
   the peer does not guarantee the peer's reachability, and if the
   destination address becomes unreachable during zero window probing,
   SCTP cannot get an updated rwnd until it switches the destination
   address for probes.

3.20.2.  Text Changes to the Document

   ---------
   Old text: (Section 6.1 A))
   ---------

   If the sender continues to receive new packets from the receiver
   while doing zero window probing, the unacknowledged window probes
   should not increment the error counter for the association or any
   destination transport address.  This is because the receiver MAY keep
   its window closed for an indefinite time.  Refer to Section 6.2 on
   the receiver behavior when it advertises a zero window.

   ---------
   New text: (Section 6.1 A))
   ---------

   If the sender continues to receive SACKs from the peer while doing
   zero window probing, the unacknowledged window probes SHOULD NOT
   increment the error counter for the association or any destination
Top   ToC   Page 29
   transport address.  This is because the receiver could keep its
   window closed for an indefinite time.  Section 6.2 describes the
   receiver behavior when it advertises a zero window.

   This text is in final form and is not further updated in this
   document.

3.20.3.  Solution Description

   The new text clarifies that if the receiver continues to send SACKs,
   the sender of probes should not increment the error counter of the
   association and the destination address even if the SACKs do not
   acknowledge the probes.

3.21.  Normative Language in Section 10 of RFC 4960

3.21.1.  Description of the Problem

   Section 10 of [RFC4960] is informative.  Therefore, normative
   language such as MUST and MAY cannot be used there.  However, there
   are several places in Section 10 of [RFC4960] where MUST and MAY
   are used.

3.21.2.  Text Changes to the Document

   ---------
   Old text: (Section 10.1 E))
   ---------

   o  no-bundle flag - instructs SCTP not to bundle this user data with
      other outbound DATA chunks.  SCTP MAY still bundle even when this
      flag is present, when faced with network congestion.

   ---------
   New text: (Section 10.1 E))
   ---------

   o  no-bundle flag - instructs SCTP not to bundle this user data with
      other outbound DATA chunks.  When faced with network congestion,
      SCTP may still bundle the data, even when this flag is present.

   This text is in final form and is not further updated in this
   document.
Top   ToC   Page 30
   ---------
   Old text: (Section 10.1 G))
   ---------

   o  Stream Sequence Number - the Stream Sequence Number assigned by
      the sending SCTP peer.

   o  partial flag - if this returned flag is set to 1, then this
      Receive contains a partial delivery of the whole message.  When
      this flag is set, the stream id and Stream Sequence Number MUST
      accompany this receive.  When this flag is set to 0, it indicates
      that no more deliveries will be received for this Stream Sequence
      Number.

   ---------
   New text: (Section 10.1 G))
   ---------

   o  stream sequence number - the Stream Sequence Number assigned by
      the sending SCTP peer.

   o  partial flag - if this returned flag is set to 1, then this
      primitive contains a partial delivery of the whole message.  When
      this flag is set, the stream id and stream sequence number must
      accompany this primitive.  When this flag is set to 0, it
      indicates that no more deliveries will be received for this stream
      sequence number.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Section 10.1 N))
   ---------

   o  Stream Sequence Number - this value is returned indicating the
      Stream Sequence Number that was associated with the message.

   o  partial flag - if this returned flag is set to 1, then this
      message is a partial delivery of the whole message.  When this
      flag is set, the stream id and Stream Sequence Number MUST
      accompany this receive.  When this flag is set to 0, it indicates
      that no more deliveries will be received for this Stream Sequence
      Number.
Top   ToC   Page 31
   ---------
   New text: (Section 10.1 N))
   ---------

   o  stream sequence number - this value is returned indicating the
      Stream Sequence Number that was associated with the message.

   o  partial flag - if this returned flag is set to 1, then this
      message is a partial delivery of the whole message.  When this
      flag is set, the stream id and stream sequence number must
      accompany this primitive.  When this flag is set to 0, it
      indicates that no more deliveries will be received for this stream
      sequence number.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Section 10.1 O))
   ---------

   o  Stream Sequence Number - this value is returned indicating the
      Stream Sequence Number that was associated with the message.

   o  partial flag - if this returned flag is set to 1, then this
      message is a partial delivery of the whole message.  When this
      flag is set, the stream id and Stream Sequence Number MUST
      accompany this receive.  When this flag is set to 0, it indicates
      that no more deliveries will be received for this Stream Sequence
      Number.

   ---------
   New text: (Section 10.1 O))
   ---------

   o  stream sequence number - this value is returned indicating the
      Stream Sequence Number that was associated with the message.

   o  partial flag - if this returned flag is set to 1, then this
      message is a partial delivery of the whole message.  When this
      flag is set, the stream id and stream sequence number must
      accompany this primitive.  When this flag is set to 0, it
      indicates that no more deliveries will be received for this stream
      sequence number.

   This text is in final form and is not further updated in this
   document.
Top   ToC   Page 32
3.21.3.  Solution Description

   The normative language is removed from Section 10.  In addition, the
   consistency of the text has been improved.

3.22.  Increase of partial_bytes_acked in Congestion Avoidance

3.22.1.  Description of the Problem

   Two issues have been discovered in the text in Section 7.2.2 of
   [RFC4960] regarding partial_bytes_acked handling:

   o  If the Cumulative TSN Ack Point is not advanced but the SACK chunk
      acknowledges new TSNs in the Gap Ack Blocks, these newly
      acknowledged TSNs are not considered for partial_bytes_acked even
      though these TSNs were successfully received by the peer.

   o  Duplicate TSNs are not considered in partial_bytes_acked even
      though they confirm that the DATA chunks were successfully
      received by the peer.

3.22.2.  Text Changes to the Document

   ---------
   Old text: (Section 7.2.2)
   ---------

   o  Whenever cwnd is greater than ssthresh, upon each SACK arrival
      that advances the Cumulative TSN Ack Point, increase
      partial_bytes_acked by the total number of bytes of all new chunks
      acknowledged in that SACK including chunks acknowledged by the new
      Cumulative TSN Ack and by Gap Ack Blocks.

   ---------
   New text: (Section 7.2.2)
   ---------

   o  Whenever cwnd is greater than ssthresh, upon each SACK arrival,
      increase partial_bytes_acked by the total number of bytes of all
      new chunks acknowledged in that SACK, including chunks
      acknowledged by the new Cumulative TSN Ack, by Gap Ack Blocks,
      and by the number of bytes of duplicated chunks reported in
      Duplicate TSNs.

   This text has been modified by multiple errata.  It is further
   updated in Section 3.26.
Top   ToC   Page 33
3.22.3.  Solution Description

   In the new text, partial_bytes_acked is increased by TSNs reported as
   duplicated, as well as TSNs newly acknowledged in Gap Ack Blocks,
   even if the Cumulative TSN Ack Point is not advanced.

3.23.  Inconsistent Handling of Notifications

3.23.1.  Description of the Problem

   [RFC4960] uses inconsistent normative and non-normative language when
   describing rules for sending notifications to the upper layer.  For
   example, Section 8.2 of [RFC4960] says that when a destination
   address becomes inactive due to an unacknowledged DATA chunk or
   HEARTBEAT chunk, SCTP SHOULD send a notification to the upper layer;
   however, Section 8.3 of [RFC4960] says that when a destination
   address becomes inactive due to an unacknowledged HEARTBEAT chunk,
   SCTP may send a notification to the upper layer.

   These inconsistent descriptions need to be corrected.

3.23.2.  Text Changes to the Document

   ---------
   Old text: (Section 8.1)
   ---------

   An endpoint shall keep a counter on the total number of consecutive
   retransmissions to its peer (this includes retransmissions to all the
   destination transport addresses of the peer if it is multi-homed),
   including unacknowledged HEARTBEAT chunks.

   ---------
   New text: (Section 8.1)
   ---------

   An endpoint SHOULD keep a counter on the total number of consecutive
   retransmissions to its peer (this includes data retransmissions to
   all the destination transport addresses of the peer if it is
   multi-homed), including the number of unacknowledged HEARTBEAT chunks
   observed on the path that is currently used for data transfer.
   Unacknowledged HEARTBEAT chunks observed on paths different from the
   path currently used for data transfer SHOULD NOT increment the
   association error counter, as this could lead to association closure
   even if the path that is currently used for data transfer is
   available (but idle).  If the value of this counter exceeds the limit
   indicated in the protocol parameter 'Association.Max.Retrans', the
   endpoint SHOULD consider the peer endpoint unreachable and SHALL stop
Top   ToC   Page 34
   transmitting any more data to it (and thus the association enters the
   CLOSED state).  In addition, the endpoint SHOULD report the failure
   to the upper layer and optionally report back all outstanding user
   data remaining in its outbound queue.  The association is
   automatically closed when the peer endpoint becomes unreachable.

   This text has been modified by multiple errata.  It includes
   modifications from Section 3.6.  It is in final form and is not
   further updated in this document.

   ---------
   Old text: (Section 8.2)
   ---------

   When an outstanding TSN is acknowledged or a HEARTBEAT sent to that
   address is acknowledged with a HEARTBEAT ACK, the endpoint shall
   clear the error counter of the destination transport address to which
   the DATA chunk was last sent (or HEARTBEAT was sent).  When the peer
   endpoint is multi-homed and the last chunk sent to it was a
   retransmission to an alternate address, there exists an ambiguity as
   to whether or not the acknowledgement should be credited to the
   address of the last chunk sent.  However, this ambiguity does not
   seem to bear any significant consequence to SCTP behavior.  If this
   ambiguity is undesirable, the transmitter may choose not to clear the
   error counter if the last chunk sent was a retransmission.

   ---------
   New text: (Section 8.2)
   ---------

   When an outstanding TSN is acknowledged or a HEARTBEAT sent to that
   address is acknowledged with a HEARTBEAT ACK, the endpoint SHOULD
   clear the error counter of the destination transport address to which
   the DATA chunk was last sent (or HEARTBEAT was sent) and SHOULD also
   report to the upper layer when an inactive destination address is
   marked as active.  When the peer endpoint is multi-homed and the last
   chunk sent to it was a retransmission to an alternate address, there
   exists an ambiguity as to whether or not the acknowledgement could be
   credited to the address of the last chunk sent.  However, this
   ambiguity does not seem to have significant consequences for SCTP
   behavior.  If this ambiguity is undesirable, the transmitter MAY
   choose not to clear the error counter if the last chunk sent was a
   retransmission.

   This text is in final form and is not further updated in this
   document.
Top   ToC   Page 35
   ---------
   Old text: (Section 8.3)
   ---------

   When the value of this counter reaches the protocol parameter
   'Path.Max.Retrans', the endpoint should mark the corresponding
   destination address as inactive if it is not so marked, and may also
   optionally report to the upper layer the change of reachability of
   this destination address.  After this, the endpoint should continue
   HEARTBEAT on this destination address but should stop increasing the
   counter.

   ---------
   New text: (Section 8.3)
   ---------

   When the value of this counter exceeds the protocol parameter
   'Path.Max.Retrans', the endpoint SHOULD mark the corresponding
   destination address as inactive if it is not so marked and SHOULD
   also report to the upper layer the change in reachability of this
   destination address.  After this, the endpoint SHOULD continue
   HEARTBEAT on this destination address but SHOULD stop increasing the
   counter.

   This text has been modified by multiple errata.  It includes
   modifications from Section 3.1.  It 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
   SHOULD clear the error counter of the destination transport address
   to which the HEARTBEAT was sent and mark the destination transport
Top   ToC   Page 36
   address as active if it is not so marked.  The endpoint SHOULD 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 includes
   modifications from Section 3.13.  It is in final form and is not
   further updated in this document.

   ---------
   Old text: (Section 9.2)
   ---------

   An endpoint should limit the number of retransmissions of the
   SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'.
   If this threshold is exceeded, the endpoint should destroy the TCB
   and MUST report the peer endpoint unreachable to the upper layer (and
   thus the association enters the CLOSED state).

   ---------
   New text: (Section 9.2)
   ---------

   An endpoint SHOULD limit the number of retransmissions of the
   SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'.
   If this threshold is exceeded, the endpoint SHOULD destroy the TCB
   and SHOULD report the peer endpoint unreachable to the upper layer
   (and thus the association enters the CLOSED state).

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Section 9.2)
   ---------

   The sender of the SHUTDOWN ACK should limit the number of
   retransmissions of the SHUTDOWN ACK chunk to the protocol parameter
   'Association.Max.Retrans'.  If this threshold is exceeded, the
   endpoint should destroy the TCB and may report the peer endpoint
   unreachable to the upper layer (and thus the association enters the
   CLOSED state).
Top   ToC   Page 37
   ---------
   New text: (Section 9.2)
   ---------

   The sender of the SHUTDOWN ACK SHOULD limit the number of
   retransmissions of the SHUTDOWN ACK chunk to the protocol parameter
   'Association.Max.Retrans'.  If this threshold is exceeded, the
   endpoint SHOULD destroy the TCB and SHOULD report the peer endpoint
   unreachable to the upper layer (and thus the association enters the
   CLOSED state).

   This text is in final form and is not further updated in this
   document.

3.23.3.  Solution Description

   The inconsistencies are removed by consistently using SHOULD.

3.24.  SACK.Delay Not Listed as a Protocol Parameter

3.24.1.  Description of the Problem

   SCTP as specified in [RFC4960] supports delaying SACKs.  The timer
   value for this is a parameter, and Section 6.2 of [RFC4960] specifies
   a default and maximum value for it.  However, (1) defining a name for
   this parameter and (2) listing it in the table of protocol parameters
   in Section 15 of [RFC4960] are missing.

   This issue was reported as an errata for [RFC4960] with
   Errata ID 4656.

3.24.2.  Text Changes to the Document

   ---------
   Old text: (Section 6.2)
   ---------

   An implementation MUST NOT allow the maximum delay to be configured
   to be more than 500 ms.  In other words, an implementation MAY lower
   this value below 500 ms but MUST NOT raise it above 500 ms.
Top   ToC   Page 38
   ---------
   New text: (Section 6.2)
   ---------

   An implementation MUST NOT allow the maximum delay (protocol
   parameter 'SACK.Delay') to be configured to be more than 500 ms.  In
   other words, an implementation MAY lower the value of SACK.Delay
   below 500 ms but MUST NOT raise it above 500 ms.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Section 15)
   ---------

   The following protocol parameters are RECOMMENDED:

      RTO.Initial - 3 seconds
      RTO.Min - 1 second
      RTO.Max - 60 seconds
      Max.Burst - 4
      RTO.Alpha - 1/8
      RTO.Beta - 1/4
      Valid.Cookie.Life - 60 seconds
      Association.Max.Retrans - 10 attempts
      Path.Max.Retrans - 5 attempts (per destination address)
      Max.Init.Retransmits - 8 attempts
      HB.interval - 30 seconds
      HB.Max.Burst - 1
Top   ToC   Page 39
   ---------
   New text: (Section 15)
   ---------

   The following protocol parameters are RECOMMENDED:

      RTO.Initial: 3 seconds
      RTO.Min: 1 second
      RTO.Max: 60 seconds
      Max.Burst: 4
      RTO.Alpha: 1/8
      RTO.Beta: 1/4
      Valid.Cookie.Life: 60 seconds
      Association.Max.Retrans: 10 attempts
      Path.Max.Retrans: 5 attempts (per destination address)
      Max.Init.Retransmits: 8 attempts
      HB.interval: 30 seconds
      HB.Max.Burst: 1
      SACK.Delay: 200 milliseconds

   This text has been modified by multiple errata.  It is further
   updated in Section 3.32.

3.24.3.  Solution Description

   The parameter is given the name 'SACK.Delay' and added to the list of
   protocol parameters.

3.25.  Processing of Chunks in an Incoming SCTP Packet

3.25.1.  Description of the Problem

   There are a few places in [RFC4960] where text specifies that the
   receiver of a packet must discard it while processing the chunks of
   the packet.  Whether or not the receiver has to roll back state
   changes already performed while processing the packet is unclear.

   The intention of [RFC4960] is to process an incoming packet chunk by
   chunk and not to perform any prescreening of chunks in the received
   packet.  Thus, by discarding one chunk, the receiver also causes the
   discarding of all further chunks.
Top   ToC   Page 40
3.25.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.2)
   ---------

   00 -  Stop processing this SCTP packet and discard it, do not
         process any further chunks within it.

   01 -  Stop processing this SCTP packet and discard it, do not
         process any further chunks within it, and report the
         unrecognized chunk in an 'Unrecognized Chunk Type'.

   ---------
   New text: (Section 3.2)
   ---------

   00 -  Stop processing this SCTP packet; discard the unrecognized
         chunk and all further chunks.

   01 -  Stop processing this SCTP packet, discard the unrecognized
         chunk and all further chunks, and report the unrecognized
         chunk in an 'Unrecognized Chunk Type'.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Section 11.3)
   ---------

   It is helpful for some firewalls if they can inspect just the first
   fragment of a fragmented SCTP packet and unambiguously determine
   whether it corresponds to an INIT chunk (for further information,
   please refer to [RFC1858]).  Accordingly, we stress the requirements,
   stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled
   with any other chunk in a packet, and (2) a packet containing an INIT
   chunk MUST have a zero Verification Tag.  Furthermore, we require
   that the receiver of an INIT chunk MUST enforce these rules by
   silently discarding an arriving packet with an INIT chunk that is
   bundled with other chunks or has a non-zero verification tag and
   contains an INIT-chunk.
Top   ToC   Page 41
   ---------
   New text: (Section 11.3)
   ---------

   It is helpful for some firewalls if they can inspect just the first
   fragment of a fragmented SCTP packet and unambiguously determine
   whether it corresponds to an INIT chunk (for further information,
   please refer to [RFC1858]).  Accordingly, we stress the requirements,
   as stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled
   with any other chunk in a packet and (2) a packet containing an INIT
   chunk MUST have a zero Verification Tag.  The receiver of an INIT
   chunk MUST silently discard the INIT chunk and all further chunks if
   the INIT chunk is bundled with other chunks or the packet has a
   non-zero Verification Tag.

   This text is in final form and is not further updated in this
   document.

3.25.3.  Solution Description

   The new text makes it clear that chunks can be processed from the
   beginning to the end and that no rollback or prescreening is
   required.



(page 41 continued on part 4)

Next Section