tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4460

Informational
Pages: 109
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: TSVWG

Stream Control Transmission Protocol (SCTP) Specification Errata and Issues

Part 1 of 4, p. 1 to 25
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part