Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4460

Stream Control Transmission Protocol (SCTP) Specification Errata and Issues

Pages: 109
Obsoleted by:  9260
Part 1 of 4 – Pages 1 to 25
None   None   Next

Top   ToC   RFC4460 - Page 1
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
Top   ToC   RFC4460 - Page 2
      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
Top   ToC   RFC4460 - Page 3
      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
Top   ToC   RFC4460 - Page 4
           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
Top   ToC   RFC4460 - Page 5
           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
Top   ToC   RFC4460 - Page 6
           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.
Top   ToC   RFC4460 - Page 7

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.
Top   ToC   RFC4460 - Page 8

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.
Top   ToC   RFC4460 - Page 9

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.
Top   ToC   RFC4460 - Page 10
      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
Top   ToC   RFC4460 - Page 11
   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.
Top   ToC   RFC4460 - Page 12
   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.
Top   ToC   RFC4460 - Page 13
   ---------
   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.
Top   ToC   RFC4460 - Page 14

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.
Top   ToC   RFC4460 - Page 15
   ---------
   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).
Top   ToC   RFC4460 - Page 16
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         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.
Top   ToC   RFC4460 - Page 17
   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
Top   ToC   RFC4460 - Page 18
   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.
Top   ToC   RFC4460 - Page 19

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.
Top   ToC   RFC4460 - Page 20

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.
Top   ToC   RFC4460 - Page 21
            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:
Top   ToC   RFC4460 - Page 22
   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.
Top   ToC   RFC4460 - Page 23
   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:
Top   ToC   RFC4460 - Page 24
   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:
Top   ToC   RFC4460 - Page 25
      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)

Next Section