RFC 4460
Stream Control Transmission Protocol (SCTP) Specification Errata and Issues
Network Working Group R. Stewart Request for Comments: 4460 Cisco Systems, Inc. Category: Informational I. Arias-Rodriguez Nokia Research Center K. Poon Sun Microsystems, Inc. A. Caro BBN Technologies M. Tuexen Muenster Univ. of Applied Sciences April 2006 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).Abstract
This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the delta, a description of the problem and the details of the solution are also provided.Table of Contents
1. Introduction ....................................................6 1.1. Conventions ................................................7 2. Corrections to RFC 2960 .........................................7 2.1. Incorrect Error Type During Chunk Processing. ..............7 2.1.1. Description of the Problem ..........................7 2.1.2. Text changes to the document ........................7 2.1.3. Solution Description ................................7
2.2. Parameter Processing Issue .................................7
2.2.1. Description of the Problem ..........................7
2.2.2. Text Changes to the Document ........................8
2.2.3. Solution Description ................................8
2.3. Padding Issues .............................................8
2.3.1. Description of the Problem ..........................8
2.3.2. Text Changes to the Document ........................9
2.3.3. Solution Description ...............................10
2.4. Parameter Types across All Chunk Types ....................10
2.4.1. Description of the Problem .........................10
2.4.2. Text Changes to the Document .......................10
2.4.3. Solution Description ...............................12
2.5. Stream Parameter Clarification ............................12
2.5.1. Description of the problem .........................12
2.5.2. Text Changes to the Document .......................12
2.5.3. Solution Description ...............................13
2.6. Restarting Association Security Issue .....................13
2.6.1. Description of the Problem .........................13
2.6.2. Text Changes to the Document .......................14
2.6.3. Solution Description ...............................18
2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes ...........19
2.7.1. Description of the Problem .........................19
2.7.2. Text Changes to the Document .......................19
2.7.3. Solution Description ...............................19
2.8. Issues with Fast Retransmit ...............................19
2.8.1. Description of the Problem .........................19
2.8.2. Text Changes to the Document .......................20
2.8.3. Solution Description ...............................23
2.9. Missing Statement about partial_bytes_acked Update ........24
2.9.1. Description of the Problem .........................24
2.9.2. Text Changes to the Document .......................24
2.9.3. Solution Description ...............................25
2.10. Issues with Heartbeating and Failure Detection ...........25
2.10.1. Description of the Problem ........................25
2.10.2. Text Changes to the Document ......................26
2.10.3. Solution Description ..............................28
2.11. Security interactions with firewalls .....................29
2.11.1. Description of the Problem ........................29
2.11.2. Text Changes to the Document ......................29
2.11.3. Solution Description ..............................31
2.12. Shutdown Ambiguity .......................................31
2.12.1. Description of the Problem ........................31
2.12.2. Text Changes to the Document ......................31
2.12.3. Solution Description ..............................32
2.13. Inconsistency in ABORT Processing ........................32
2.13.1. Description of the Problem ........................32
2.13.2. Text changes to the document ......................33
2.13.3. Solution Description ..............................33
2.14. Cwnd Gated by Its Full Use ...............................34
2.14.1. Description of the Problem ........................34
2.14.2. Text Changes to the Document ......................34
2.14.3. Solution Description ..............................36
2.15. Window Probes in SCTP ....................................36
2.15.1. Description of the Problem ........................36
2.15.2. Text Changes to the Document ......................36
2.15.3. Solution Description ..............................38
2.16. Fragmentation and Path MTU Issues ........................39
2.16.1. Description of the Problem ........................39
2.16.2. Text Changes to the Document ......................39
2.16.3. Solution Description ..............................40
2.17. Initial Value of the Cumulative TSN Ack ..................40
2.17.1. Description of the Problem ........................40
2.17.2. Text Changes to the Document ......................40
2.17.3. Solution Description ..............................41
2.18. Handling of Address Parameters within the INIT or
INIT-ACK .................................................41
2.18.1. Description of the Problem ........................41
2.18.2. Text Changes to the Document ......................41
2.18.3. Solution description ..............................42
2.19. Handling of Stream Shortages .............................42
2.19.1. Description of the Problem ........................42
2.19.2. Text Changes to the Document ......................42
2.19.3. Solution Description ..............................43
2.20. Indefinite Postponement ..................................43
2.20.1. Description of the Problem ........................43
2.20.2. Text Changes to the Document ......................43
2.20.3. Solution Description ..............................44
2.21. User-Initiated Abort of an Association ...................44
2.21.1. Description of the Problem ........................44
2.21.2. Text changes to the document ......................44
2.21.3. Solution Description ..............................50
2.22. Handling of Invalid Initiate Tag of INIT-ACK .............50
2.22.1. Description of the Problem ........................50
2.22.2. Text Changes to the Document ......................50
2.22.3. Solution Description ..............................51
2.23. Sending an ABORT in Response to an INIT ..................51
2.23.1. Description of the Problem ........................51
2.23.2. Text Changes to the Document ......................51
2.23.3. Solution Description ..............................52
2.24. Stream Sequence Number (SSN) Initialization ..............52
2.24.1. Description of the Problem ........................52
2.24.2. Text Changes to the Document ......................52
2.24.3. Solution Description ..............................53
2.25. SACK Packet Format .......................................53
2.25.1. Description of the Problem ........................53
2.25.2. Text Changes to the Document ......................53
2.25.3. Solution Description ..............................53
2.26. Protocol Violation Error Cause ...........................53
2.26.1. Description of the Problem ........................53
2.26.2. Text Changes to the Document ......................54
2.26.3. Solution Description ..............................56
2.27. Reporting of Unrecognized Parameters .....................56
2.27.1. Description of the Problem ........................56
2.27.2. Text Changes to the Document ......................56
2.27.3. Solution Description ..............................57
2.28. Handling of IP Address Parameters ........................58
2.28.1. Description of the Problem ........................58
2.28.2. Text Changes to the Document ......................58
2.28.3. Solution Description ..............................58
2.29. Handling of COOKIE ECHO Chunks When a TCB Exists .........59
2.29.1. Description of the Problem ........................59
2.29.2. Text Changes to the Document ......................59
2.29.3. Solution Description ..............................59
2.30. The Initial Congestion Window Size .......................59
2.30.1. Description of the Problem ........................59
2.30.2. Text Changes to the Document ......................60
2.30.3. Solution Description ..............................61
2.31. Stream Sequence Numbers in Figures .......................62
2.31.1. Description of the Problem ........................62
2.31.2. Text Changes to the Document ......................63
2.31.3. Solution description ..............................67
2.32. Unrecognized Parameters ..................................67
2.32.1. Description of the Problem ........................67
2.32.2. Text Changes to the Document ......................67
2.32.3. Solution Description ..............................68
2.33. Handling of Unrecognized Parameters ......................68
2.33.1. Description of the Problem ........................68
2.33.2. Text Changes to the Document ......................68
2.33.3. Solution Description ..............................70
2.34. Tie Tags .................................................70
2.34.1. Description of the Problem ........................70
2.34.2. Text Changes to the Document ......................70
2.34.3. Solution Description ..............................72
2.35. Port Number Verification in the COOKIE-ECHO ..............72
2.35.1. Description of the Problem ........................72
2.35.2. Text Changes to the Document ......................72
2.35.3. Solution Description ..............................73
2.36. Path Initialization ......................................74
2.36.1. Description of the Problem ........................74
2.36.2. Text Changes to the Document ......................74
2.36.3. Solution Description ..............................76
2.37. ICMP Handling Procedures .................................76
2.37.1. Description of the Problem ........................76
2.37.2. Text Changes to the Document ......................77
2.37.3. Solution Description ..............................79
2.38. Checksum .................................................79
2.38.1. Description of the problem ........................79
2.38.2. Text Changes to the Document ......................79
2.38.3. Solution Description ..............................86
2.39. Retransmission Policy ....................................86
2.39.1. Description of the Problem ........................86
2.39.2. Text Changes to the Document ......................87
2.39.3. Solution Description ..............................87
2.40. Port Number 0 ............................................88
2.40.1. Description of the Problem ........................88
2.40.2. Text Changes to the Document ......................88
2.40.3. Solution Description ..............................89
2.41. T Bit ....................................................89
2.41.1. Description of the Problem ........................89
2.41.2. Text Changes to the Document ......................89
2.41.3. Solution Description ..............................93
2.42. Unknown Parameter Handling ...............................93
2.42.1. Description of the Problem ........................93
2.42.2. Text Changes to the Document ......................93
2.42.3. Solution Description ..............................95
2.43. Cookie Echo Chunk ........................................95
2.43.1. Description of the Problem ........................95
2.43.2. Text Changes to the Document ......................95
2.43.3. Solution Description ..............................96
2.44. Partial Chunks ...........................................96
2.44.1. Description of the Problem ........................96
2.44.2. Text Changes to the Document ......................96
2.44.3. Solution Description ..............................97
2.45. Non-unicast Addresses ....................................97
2.45.1. Description of the Problem ........................97
2.45.2. Text Changes to the Document ......................97
2.45.3. Solution Description ..............................98
2.46. Processing of ABORT Chunks ...............................98
2.46.1. Description of the Problem ........................98
2.46.2. Text Changes to the Document ......................98
2.46.3. Solution Description ..............................98
2.47. Sending of ABORT Chunks ..................................99
2.47.1. Description of the Problem ........................99
2.47.2. Text Changes to the Document ......................99
2.47.3. Solution Description ..............................99
2.48. Handling of Supported Address Types Parameter ............99
2.48.1. Description of the Problem ........................99
2.48.2. Text Changes to the Document .....................100
2.48.3. Solution Description .............................100
2.49. Handling of Unexpected Parameters .......................101
2.49.1. Description of the Problem .......................101
2.49.2. Text Changes to the Document .....................101
2.49.3. Solution Description .............................102
2.50. Payload Protocol Identifier .............................102
2.50.1. Description of the Problem .......................102
2.50.2. Text Changes to the Document .....................103
2.50.3. Solution Description .............................103
2.51. Karn's Algorithm ........................................104
2.51.1. Description of the Problem .......................104
2.51.2. Text Changes to the Document .....................104
2.51.3. Solution Description .............................104
2.52. Fast Retransmit Algorithm ...............................104
2.52.1. Description of the Problem .......................104
2.52.2. Text Changes to the Document .....................105
2.52.3. Solution Description .............................105
3. Security Considerations .......................................105
4. Acknowledgements ..............................................106
5. IANA Considerations ...........................................106
6. Normative References ..........................................106
1. Introduction
This document contains a compilation of all defects found up until
the publishing of this document for the Stream Control Transmission
Protocol (SCTP), RFC 2960 [5]. These defects may be of an editorial
or technical nature. This document may be thought of as a companion
document to be used in the implementation of SCTP to clarify errors
in the original SCTP document.
This document provides a history of the changes that will be compiled
into RFC 2960's [5] BIS document. Each error will be detailed within
this document in the form of
o the problem description,
o the text quoted from RFC 2960 [5],
o the replacement text that should be placed into the BIS document,
and
o a description of the solution.
This document is a historical record of sequential changes what have
been found necessary at various interop events and through discussion
on this list.
Note that because some text is changed several times, the last delta
for a text in the document is the erratum for that text in RFC 2960.
1.1. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [2].2. Corrections to RFC 2960
2.1. Incorrect Error Type During Chunk Processing.
2.1.1. Description of the Problem
A typo was discovered in RFC 2960 [5] that incorrectly specifies an action to be taken when processing chunks of unknown identity.2.1.2. Text changes to the document
--------- Old text: (Section 3.2) --------- 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK). --------- New text: (Section 3.2) --------- 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'.2.1.3. Solution Description
The receiver of an unrecognized chunk should not send a 'parameter' error but instead should send the appropriate chunk error as described above.2.2. Parameter Processing Issue
2.2.1. Description of the Problem
A typographical error was introduced through an improper cut and paste in the use of the upper two bits to describe proper handling of unknown parameters.
2.2.2. Text Changes to the Document
--------- Old text: (Section 3.2.1) --------- 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 parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK). --------- New text: (Section 3.2.1) --------- 00 - Stop processing this SCTP chunk and discard it, do not process any further parameters within this chunk. 01 - Stop processing this SCTP chunk and discard it, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).2.2.3. Solution Description
It was always the intent to stop processing at the level one was at in an unknown chunk or parameter with the upper bit set to 0. Thus, if you are processing a chunk, you should drop the packet. If you are processing a parameter, you should drop the chunk.2.3. Padding Issues
2.3.1. Description of the Problem
A problem was found when a Chunk terminated in a TLV parameter. If this last TLV was not on a 32-bit boundary (as required), there was confusion as to whether the last padding was included in the chunk length.
2.3.2. Text Changes to the Document
--------- Old text: (Section 3.2) --------- Chunk Length: 16 bits (unsigned integer) This value represents the size of the chunk in bytes including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any padding. Chunk Value: variable length The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type. The total length of a chunk (including Type, Length and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes and this padding is not included in the chunk length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes. --------- New text: (Section 3.2) --------- Chunk Length: 16 bits (unsigned integer) This value represents the size of the chunk in bytes, including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any chunk padding. Chunks (including Type, Length, and Value fields) are padded out by the sender with all zero bytes to be a multiple of 4 bytes long. This padding MUST NOT be more than 3 bytes in total. The Chunk Length value does not include terminating padding of the chunk. However, it does include padding of any variable-length parameter except the last parameter in the chunk. The receiver MUST ignore the padding.
Note: A robust implementation should accept the Chunk whether or
not the final padding has been included in the Chunk Length.
Chunk Value: variable length
The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field is
dependent on the Chunk Type.
The total length of a chunk (including Type, Length, and Value
fields) MUST be a multiple of 4 bytes. If the length of the chunk is
not a multiple of 4 bytes, the sender MUST pad the chunk with all
zero bytes, and this padding is not included in the chunk length
field. The sender should never pad with more than 3 bytes. The
receiver MUST ignore the padding bytes.
2.3.3. Solution Description
The above text makes clear that the padding of the last parameter is
not included in the Chunk Length field. It also clarifies that the
padding of parameters that are not the last one must be counted in
the Chunk Length field.
2.4. Parameter Types across All Chunk Types
2.4.1. Description of the Problem
A problem was noted when multiple errors are needed to be sent
regarding unknown or unrecognized parameters. Since often the error
type does not hold the chunk type field, it may become difficult to
tell which error was associated with which chunk.
2.4.2. Text Changes to the Document
---------
Old text: (Section 3.2.1)
---------
The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are
defined in Section 13.2.
---------
New text: (Section 3.2.1)
---------
The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are
defined in Section 13.2. Note that a parameter type MUST be unique across all chunks. For example, the parameter type '5' is used to represent an IPv4 address (see Section 3.3.2). The value '5' then is reserved across all chunks to represent an IPv4 address and MUST NOT be reused with a different meaning in any other chunk. --------- Old text: (Section 13.2) --------- 13.2 IETF-defined Chunk Parameter Extension The assignment of new chunk parameter type codes is done through an IETF Consensus action as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information: a) Name of the parameter type. b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2.1. c) Detailed definition of each component of the parameter type. d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk. --------- New text: (Section 13.2) --------- 13.2. IETF-defined Chunk Parameter Extension The assignment of new chunk parameter type codes is done through an IETF Consensus action, as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information: a) Name of the parameter type. b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2.1. c) Detailed definition of each component of the parameter type.
d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple
instances of this parameter type may be found within the same
chunk.
e) Each parameter type MUST be unique across all chunks.
2.4.3. Solution Description
By having all parameters unique across all chunk assignments (the
current assignment policy), no ambiguity exists as to what a
parameter means in different contexts. The trade-off for this is a
smaller parameter space, i.e., 65,536 parameters versus 65,536 *
Number-of- chunks.
2.5. Stream Parameter Clarification
2.5.1. Description of the problem
A problem was found where the specification is unclear on the
legality of an endpoint asking for more stream resources than were
allowed in the MIS value of the INIT. In particular, the value in
the INIT ACK requested in its OS value was larger than the MIS value
received in the INIT chunk. This behavior is illegal, yet it was
unspecified in RFC 2960 [5]
2.5.2. Text Changes to the Document
---------
Old text: (Section 3.3.3)
---------
Number of Outbound Streams (OS): 16 bits (unsigned integer)
Defines the number of outbound streams the sender of this INIT ACK
chunk wishes to create in this association. The value of 0 MUST
NOT be used.
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
destroy the association discarding its TCB.
--------- New text: (Section 3.3.3) --------- Number of Outbound Streams (OS): 16 bits (unsigned integer) Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used, and the value MUST NOT be greater than the MIS value sent in the INIT chunk. Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association, discarding its TCB.2.5.3. Solution Description
The change in wording, above, changes it so that a responder to an INIT chunk does not specify more streams in its OS value than were represented to it in the MIS value, i.e., its maximum.2.6. Restarting Association Security Issue
2.6.1. Description of the Problem
A security problem was found when a restart occurs. It is possible for an intruder to send an INIT to an endpoint of an existing association. In the INIT the intruder would list one or more of the current addresses of an association and its own. The normal restart procedures would then occur, and the intruder would have hijacked an association.
2.6.2. Text Changes to the Document
--------- Old text: (Section 3.3.10) --------- Cause Code Value Cause Code --------- ---------------- 1 Invalid Stream Identifier 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields Cause-specific Information: variable length This field carries the details of the error condition. Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
--------- New text: (Section 3.3.10) --------- Cause Code Value Cause Code --------- ---------------- 1 Invalid Stream Identifier 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down 11 Restart of an Association with New Addresses Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields. Cause-specific Information: variable length This field carries the details of the error condition. Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3. --------- New text: (Note no old text, new error cause added in section 3.3.10) --------- 3.3.10.11. Restart of an Association with New Addresses (11) Cause of error -------------- Restart of an association with new addresses: An INIT was received on an existing association. But the INIT added addresses to the association that were previously NOT part of the association. The new addresses are listed in the error code. This ERROR is normally sent as part of an ABORT refusing the INIT (see Section 5.2).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Each New Address TLV is an exact copy of the TLV
that was found in the INIT chunk that was new, including the
Parameter Type and the Parameter length.
---------
Old text: (Section 5.2.1)
---------
Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an
endpoint MUST respond with an INIT ACK using the same parameters it
sent in its original INIT chunk (including its Initiation Tag,
unchanged). These original parameters are combined with those from
the newly received INIT chunk. The endpoint shall also generate a
State Cookie with the INIT ACK. The endpoint uses the parameters
sent in its INIT to calculate the State Cookie.
---------
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 Initiation 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 to.
Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
respond with an INIT ACK using the same parameters it sent in its
original INIT chunk (including its Initiation Tag, unchanged),
provided that no NEW address has been added to the forming
association. If the INIT message indicates that a new address has
been added to the association, then the entire INIT MUST be
discarded, and NO changes should be made to the existing association.
An ABORT SHOULD be sent in response that MAY include the error
'Restart of an association with new addresses'. The error SHOULD
list the addresses that were added to the restarting association.
When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with an INIT ACK, the original parameters are combined with those from the newly received INIT chunk. The endpoint shall also generate a State Cookie with the INIT ACK. The endpoint uses the parameters sent in its INIT to calculate the State Cookie. --------- Old text: (Section 5.2.2) --------- 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT Unless otherwise stated, upon reception of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. In the outbound INIT ACK the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie. After sending out the INIT ACK, the endpoint shall take no further actions, i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed. Note: Only when a TCB exists and the association is not in a COOKIE- WAIT state are the Tie-Tags populated. For a normal association INIT (i.e., the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed). The INIT ACK and State Cookie are populated as specified in section 5.2.1. --------- New text: (Section 5.2.2) --------- 5.2.2. Unexpected INIT in States Other Than CLOSED, COOKIE-ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT Unless otherwise stated, upon receipt of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. Before responding, the endpoint MUST check to see if the unexpected INIT adds new addresses to the association. If new addresses are added to the association, the endpoint MUST respond
with an ABORT, copying the 'Initiation Tag' of the unexpected INIT into the 'Verification Tag' of the outbound packet carrying the ABORT. In the ABORT response, the cause of error MAY be set to 'restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association. If no new addresses are added, when responding to the INIT in the outbound INIT ACK, the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie- Tag and the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated; see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie. After sending out the INIT ACK or ABORT, the endpoint shall take no further actions; i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed. Note: Only when a TCB exists and the association is not in a COOKIE- WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a value other than 0. For a normal association INIT (i.e., the endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed).2.6.3. Solution Description
A new error code is being added, along with specific instructions to send back an ABORT to a new association in a restart case or collision case, where new addresses have been added. The error code can be used by a legitimate restart to inform the endpoint that it has made a software error in adding a new address. The endpoint then can choose to wait until the OOTB ABORT tears down the old association, or to restart without the new address. Also, the note at the end of Section 5.2.2 explaining the use of the Tie-Tags was modified to properly explain the states in which the Tie-Tags should be set to a value different than 0.
2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes
2.7.1. Description of the Problem
Some implementations were having difficulty growing their cwnd. This was due to an improper enforcement of the congestion control rules. The rules, as written, provided for a slop over of the cwnd value. Without this slop over, the sender would appear NOT to be using its full cwnd value and thus would never increase it.2.7.2. Text Changes to the Document
--------- Old text: (Section 6.1) --------- B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address. --------- New text: (Section 6.1) --------- B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address. The sender may exceed cwnd by up to (PMTU-1) bytes on a new transmission if the cwnd is not currently exceeded.2.7.3. Solution Description
The text changes make clear the ability to go over the cwnd value by no more than (PMTU-1) bytes.2.8. Issues with Fast Retransmit
2.8.1. Description of the Problem
Several problems were found in the current specification of fast retransmit. The current wording did not require GAP ACK blocks to be sent, even though they are essential to the workings of SCTP's congestion control. The specification left unclear how to handle the fast retransmit cycle, having the implementation wait on the cwnd to retransmit a TSN that was marked for fast retransmit. No limit was placed on how many times a TSN could be fast retransmitted. Fast Recovery was not specified, causing the congestion window to be reduced drastically when there are multiple losses in a single RTT.
2.8.2. Text Changes to the Document
--------- Old text: (Section 6.2) --------- Acknowledgements MUST be sent in SACK chunks unless shutdown was requested by the ULP in which case an endpoint MAY send an acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field SHOULD also be reported in the Gap Ack Block fields. --------- New text: (Section 6.2) --------- Acknowledegments MUST be sent in SACK chunks unless shutdown was requested by the ULP, in which case an endpoint MAY send an acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field are reported in the Gap Ack Block fields. The SCTP endpoint MUST report as many Gap Ack Blocks as can fit in a single SACK chunk limited by the current path MTU. --------- Old text: (Section 6.2.1) --------- D) Any time a SACK arrives, the endpoint performs the following: i) If Cumulative TSN Ack is less than the Cumulative TSN Ack Point, then drop the SACK. Since Cumulative TSN Ack is monotonically increasing, a SACK whose Cumulative TSN Ack is less than the Cumulative TSN Ack Point indicates an out-of- order SACK. ii) Set rwnd equal to the newly received a_rwnd minus the number of bytes still outstanding after processing the Cumulative TSN Ack and the Gap Ack Blocks.
iii) If the SACK is missing a TSN that was previously
acknowledged via a Gap Ack Block (e.g., the data receiver
reneged on the data), then mark the corresponding DATA chunk
as available for retransmit: Mark it as missing for fast
retransmit as described in Section 7.2.4 and if no
retransmit timer is running for the destination address
to which the DATA chunk was originally transmitted, then
T3-rtx is started for that destination address.
---------
New text: (Section 6.2.1)
---------
D) Any time a SACK arrives, the endpoint performs the following:
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
Point, then drop the SACK. Since Cumulative TSN Ack is
monotonically increasing, a SACK whose Cumulative TSN Ack is
less than the Cumulative TSN Ack Point indicates an out-of-
order SACK.
ii) Set rwnd equal to the newly received a_rwnd minus the
number of bytes still outstanding after processing the
Cumulative TSN Ack and the Gap Ack Blocks.
iii) If the SACK is missing a TSN that was previously
acknowledged via a Gap Ack Block (e.g., the data receiver
reneged on the data), then consider the corresponding DATA
that might be possibly missing: Count one miss indication
towards fast retransmit as described in Section 7.2.4, and
if no retransmit timer is running for the destination
address to which the DATA chunk was originally transmitted,
then T3-rtx is started for that destination address.
iv) If the Cumulative TSN Ack matches or exceeds the Fast
Recovery exitpoint (Section 7.2.4), Fast Recovery is exited.
---------
Old text: (Section 7.2.4)
---------
Whenever an endpoint receives a SACK that indicates some TSN(s)
missing, it SHOULD wait for 3 further miss indications (via
subsequent SACK's) on the same TSN(s) before taking action with
regard to Fast Retransmit.
When the TSN(s) is reported as missing in the fourth consecutive
SACK, the data sender shall:
1) Mark the missing DATA chunk(s) for retransmission,
2) Adjust the ssthresh and cwnd of the destination address(es) to
which the missing DATA chunks were last sent, according to the
formula described in Section 7.2.3.
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.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first.
A straightforward implementation of the above keeps a counter for
each TSN hole reported by a SACK. The counter increments for each
consecutive SACK reporting the TSN hole. After reaching 4 and
starting the fast retransmit procedure, the counter resets to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size.
---------
New text: (Section 7.2.4)
---------
Whenever an endpoint receives a SACK that indicates that some TSNs
are missing, it SHOULD wait for 3 further miss indications (via
subsequent SACKs) on the same TSN(s) before taking action with
regard to Fast Retransmit.
Miss indications SHOULD follow the HTNA (Highest TSN Newly
Acknowledged) algorithm. For each incoming SACK, miss
indications are incremented only for missing TSNs prior to
the highest TSN newly acknowledged in the SACK. A newly
acknowledged DATA chunk is one not previously acknowledged
in a SACK. If an endpoint is in Fast Recovery and a SACK
arrives that advances the Cumulative TSN Ack Point, the
miss indications are incremented for all TSNs reported
missing in the SACK.
When the fourth consecutive miss indication is received for a TSN(s),
the data sender shall do the following:
1) Mark the DATA chunk(s) with four miss indications for
retransmission.
2) If not in Fast Recovery, adjust the ssthresh and cwnd of the
destination address(es) to which the missing DATA chunks were
last sent, according to the formula described in Section 7.2.3.
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.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
5) Mark the DATA chunk(s) as being fast retransmitted and thus
ineligible for a subsequent fast retransmit. Those TSNs marked
for retransmission due to the Fast Retransmit algorithm that
did not fit in the sent datagram carrying K other TSNs are also
marked as ineligible for a subsequent fast retransmit. However,
as they are marked for retransmission they will be retransmitted
later on as soon as cwnd allows.
6) If not in Fast Recovery, enter Fast Recovery and mark the highest
outstanding TSN as the Fast Recovery exit point. When a SACK
acknowledges all TSNs up to and including this exit point, Fast
Recovery is exited. While in Fast Recovery, the ssthresh and cwnd
SHOULD NOT change for any destinations due to a subsequent Fast
Recovery event (i.e., one SHOULD NOT reduce the cwnd further due
to a subsequent fast retransmit).
Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first.
2.8.3. Solution Description
The effect of the above wording changes are as follows:
o It requires with a MUST the sending of GAP Ack blocks instead of
the current RFC 2960 [5] SHOULD.
o It allows a TSN being Fast Retransmitted (FR) to be sent only once
via FR.
o It ends the delay in waiting for the flight size to drop when a
TSN is identified as being ready to FR.
o It changes the way chunks are marked during fast retransmit, so
that only new reports are counted.
o It introduces a Fast Recovery period to avoid multiple congestion
window reductions when there are multiple losses in a single RTT
(as shown by Caro et al. [3]).
These changes will effectively allow SCTP to follow a similar model
as TCP+SACK in the handling of Fast Retransmit.
2.9. Missing Statement about partial_bytes_acked Update
2.9.1. Description of the Problem
SCTP uses four control variables to regulate its transmission rate:
rwnd, cwnd, ssthresh, and partial_bytes_acked. Upon detection of
packet losses from SACK, or when the T3-rtx timer expires on an
address, cwnd and ssthresh should be updated as stated in Section
7.2.3. However, that section should also clarify that
partial_bytes_acked must be updated as well; it has to be reset to 0.
2.9.2. Text Changes to the Document
---------
Old text: (Section 7.2.3)
---------
7.2.3 Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), An
endpoint should do the following:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
When the T3-rtx timer expires on an address, SCTP should perform slow
start by:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
---------
New text: (Section 7.2.3)
---------
7.2.3. Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), an
endpoint should do the following if not in Fast Recovery:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
partial_bytes_acked = 0
Basically, a packet loss causes cwnd to be cut in half.
When the T3-rtx timer expires on an address, SCTP should perform slow
start by
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
partial_bytes_acked = 0
2.9.3. Solution Description
The missing text added solves the doubts about what to do with
partial_bytes_acked in the situations stated in Section 7.2.3, making
clear that, along with ssthresh and cwnd, partial_bytes_acked should
also be updated by being reset to 0.
(page 25 continued on part 2)
