RFC 8540
Stream Control Transmission Protocol: Errata and Issues in RFC 4960
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.
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.
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
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.
--------- 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.
--------- 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.
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.
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
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.
--------- 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
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).
--------- 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.
--------- 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
--------- 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.
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.
--------- 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)
