Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4460

Stream Control Transmission Protocol (SCTP) Specification Errata and Issues

Pages: 109
Obsoleted by:  9260
Part 4 of 4 – Pages 88 to 109
First   Prev   None

Top   ToC   RFC4460 - Page 88   prevText

2.40. Port Number 0

2.40.1. Description of the Problem

The port number 0 has a special semantic in various APIs. For example, in the socket API, if the user specifies 0, the SCTP implementation chooses an appropriate port number for the user. Therefore, the port number 0 should not be used on the wire.

2.40.2. Text Changes to the Document

--------- Old text: (Section 3.1) --------- Source Port Number: 16 bits (unsigned integer) This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port, and possibly the destination IP address to identify the association to which this packet belongs. Destination Port Number: 16 bits (unsigned integer) This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application. --------- New text: (Section 3.1) --------- Source Port Number: 16 bits (unsigned integer) This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port and possibly the destination IP address to identify the association to which this packet belongs. The port number 0 MUST NOT be used. Destination Port Number: 16 bits (unsigned integer) This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application. The port number 0 MUST NOT be used.
Top   ToC   RFC4460 - Page 89

2.40.3. Solution Description

It is clearly stated that the port number 0 is an invalid value on the wire.

2.41. T Bit

2.41.1. Description of the Problem

The description of the T bit as the bit describing whether a TCB has been destroyed is misleading. In addition, the procedure described in Section 2.13 is not as precise as needed.

2.41.2. Text Changes to the Document

--------- Old text: (Section 3.3.7) --------- T bit: 1 bit The T bit is set to 0 if the sender had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1. --------- New text: (Section 3.3.7) --------- T bit: 1 bit The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one. --------- Old text: (Section 3.3.13) --------- T bit: 1 bit The T bit is set to 0 if the sender had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1.
Top   ToC   RFC4460 - Page 90
   ---------
   New text: (Section 3.3.13)
   ---------

      T bit:  1 bit
         The T bit is set to 0 if the sender filled in the
         Verification Tag expected by the peer.  If the Verification
         Tag is reflected, the T bit MUST be set to 1.  Reflecting means
         that the sent Verification Tag is the same as the received
         one.


   ---------
   Old text: (Section 8.4)
   ---------

       3) If the packet contains an INIT chunk with a Verification Tag
          set to '0', process it as described in Section 5.1.
          Otherwise,

   ---------
   New text: (Section 8.4)
   ---------
       3) If the packet contains an INIT chunk with a Verification Tag
         set to '0', process it as described in Section 5.1.  If, for
         whatever reason, the INIT cannot be processed normally and
         an ABORT has to be sent in response, the Verification Tag of
         the packet containing the ABORT chunk MUST be the Initiate
         tag of the received INIT chunk, and the T-Bit of the ABORT
         chunk has to be set to 0, indicating that the Verification
         Tag is NOT reflected.


   ---------
   Old text: (Section 8.4)
   ---------
      5) If the packet contains a SHUTDOWN ACK chunk, the receiver
         should respond to the sender of the OOTB packet with a
         SHUTDOWN COMPLETE.  When sending the SHUTDOWN COMPLETE, the
         receiver of the OOTB packet must fill in the Verification
         Tag field of the outbound packet with the Verification Tag
         received in the SHUTDOWN ACK and set the T-bit in the Chunk
         Flags to indicate that no TCB was found.  Otherwise,
Top   ToC   RFC4460 - Page 91
   ---------
   New text: (Section 8.4)
   ---------

      5) If the packet contains a SHUTDOWN ACK chunk, the receiver
         should respond to the sender of the OOTB packet with a
         SHUTDOWN COMPLETE.  When sending the SHUTDOWN COMPLETE, the
         receiver of the OOTB packet must fill in the Verification
         Tag field of the outbound packet with the Verification Tag
         received in the SHUTDOWN ACK and set the T-bit in the
         Chunk Flags to indicate that the Verification Tag is
         reflected.  Otherwise,


   ---------
   Old text: (Section 8.4)
   ---------

      8) The receiver should respond to the sender of the OOTB packet
         with an ABORT.  When sending the ABORT, the receiver of the
         OOTB packet MUST fill in the Verification Tag field of the
         outbound packet with the value found in the Verification
         Tag field of the OOTB packet and set the T-bit in the Chunk
         Flags to indicate that no TCB was found.  After sending this
         ABORT, the receiver of the OOTB packet shall discard the
         OOTB packet and take no further action.

   ---------
   New text: (Section 8.4)
   ---------

      8) The receiver should respond to the sender of the OOTB packet
         with an ABORT.  When sending the ABORT, the receiver of the
         OOTB packet MUST fill in the Verification Tag field of the
         outbound packet with the value found in the Verification Tag
         field of the OOTB packet and set the T-bit in the Chunk Flags
         to indicate that the Verification Tag is reflected.  After
         sending this ABORT, the receiver of the OOTB packet shall
         discard the OOTB packet and take no further action.


   ---------
   Old text: (Section 8.5.1)
   ---------

      B) Rules for packet carrying ABORT:
Top   ToC   RFC4460 - Page 92
         -  The endpoint shall always fill in the Verification Tag
            field of the outbound packet with the destination
            endpoint's tag value if it is known.

         -  If the ABORT is sent in response to an OOTB packet, the
            endpoint MUST follow the procedure described in
            Section 8.4.

         -  The receiver MUST accept the packet if the Verification
            Tag matches either its own tag, OR the tag of its peer.
            Otherwise, the receiver MUST silently discard the packet
            and take no further action.

   ---------
   New text: (Section 8.5.1)
   ---------

     B) Rules for packet carrying ABORT:

         -  The endpoint MUST always fill in the Verification Tag
            field of the outbound packet with the destination
            endpoint's tag value, if it is known.

         -  If the ABORT is sent in response to an OOTB packet, the
            endpoint MUST follow the procedure described in
            Section 8.4.

         -  The receiver of an ABORT MUST accept the packet
            if the Verification Tag field of the packet matches its
            own tag and the T bit is not set
            OR
            if it is set to its peer's tag and the T bit is set in
            the Chunk Flags.
            Otherwise, the receiver MUST silently discard the packet
            and take no further action.


   ---------
   Old text: (Section 8.5.1)
   ---------

      C) Rules for packet carrying SHUTDOWN COMPLETE:

         -  When sending a SHUTDOWN COMPLETE, if the receiver of the
            SHUTDOWN ACK has a TCB then the destination endpoint's
            tag MUST be used.  Only where no TCB exists should the
            sender use the Verification Tag from the SHUTDOWN ACK.
Top   ToC   RFC4460 - Page 93
         -  The receiver of a SHUTDOWN COMPLETE shall accept the
            packet if the Verification Tag field of the packet matches
            its own tag OR it is set to its peer's tag and the T bit
            is set in the Chunk Flags.  Otherwise, the receiver MUST
            silently discard the packet and take no further action.
            An endpoint MUST ignore the SHUTDOWN COMPLETE if it is
            not in the SHUTDOWN-ACK-SENT state.

   ---------
   New text: (Section 8.5.1)
   ---------

      C) Rules for packet carrying SHUTDOWN COMPLETE:

         -  When sending a SHUTDOWN COMPLETE, if the receiver of the
            SHUTDOWN ACK has a TCB, then the destination endpoint's tag
            MUST be used, and the T-bit MUST NOT be set.  Only where no
            TCB exists should the sender use the Verification Tag from
            the SHUTDOWN ACK, and MUST set the T-bit.

         -  The receiver of a SHUTDOWN COMPLETE shall accept the packet
            if the Verification Tag field of the packet matches its own
            tag and the T bit is not set
            OR
            if it is set to its peer's tag and the T bit is set in the
            Chunk Flags.
            Otherwise, the receiver MUST silently discard the packet
            and take no further action.  An endpoint MUST ignore the
            SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT
            state.

2.41.3. Solution Description

The description of the T bit now clearly describes the semantic of the bit. The procedures for receiving the T bit have been clarified.

2.42. Unknown Parameter Handling

2.42.1. Description of the Problem

The description given in Section 2.33 does not state clearly whether an INIT-ACK or COOKIE-ECHO is sent.

2.42.2. Text Changes to the Document

The changes given here already include changes suggested in Section 2.2, 2.27, and 2.33 of this document.
Top   ToC   RFC4460 - Page 94
   ---------
   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).

   10 - Skip this parameter and continue processing.

   11 - Skip this parameter and continue processing but 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 parameter; do not process
        any further parameters within this chunk.

   01 - Stop processing this parameter, do not process
        any further parameters within this chunk, and report the
        unrecognized parameter in an 'Unrecognized Parameter', as
        described in 3.2.2.

   10 - Skip this parameter and continue processing.

   11 - Skip this parameter and continue processing but report the
        unrecognized parameter in an 'Unrecognized Parameter', as
        described in 3.2.2.

   Please note that in all four cases an INIT-ACK or COOKIE-ECHO
   chunk is sent.  In the 00 or 01 case the processing of the
   parameters after the unknown parameter is canceled, but no
   processing already done is rolled back.
Top   ToC   RFC4460 - Page 95
   ---------
   New text: (Note: no old text; clarification added in Section 3.2)
   ---------

   3.2.2.  Reporting of Unrecognized Parameters

      If the receiver of an INIT chunk detects unrecognized parameters
      and has to report them according to Section 3.2.1, it MUST put
      the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk
      sent in response to the INIT-chunk.  Note that if the receiver
      of the INIT chunk is NOT going to establish an association (e.g.,
      due to lack of resources), an 'Unrecognized Parameter' would NOT
      be included with any ABORT being sent to the sender of the INIT.

      If the receiver of an INIT-ACK chunk detects unrecognized
      parameters and has to report them according to Section 3.2.1, it
      SHOULD bundle the ERROR chunk containing the 'Unrecognized
      Parameters' error cause with the COOKIE-ECHO chunk sent in
      response to the INIT-ACK chunk.  If the receiver of the INIT-ACK
      cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the
      ERROR chunk MAY be sent separately but not before the COOKIE-ACK
      has been received.

      Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
      first chunk.

2.42.3. Solution Description

The new text clearly states that an INIT-ACK or COOKIE-ECHO has to be sent.

2.43. Cookie Echo Chunk

2.43.1. Description of the Problem

The description given in Section 3.3.11 of RFC 2960 [5] is unclear as to how the COOKIE-ECHO is composed.

2.43.2. Text Changes to the Document

--------- Old text: (Section 3.3.11) --------- Cookie: variable size This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK.
Top   ToC   RFC4460 - Page 96
         An implementation SHOULD make the cookie as small as possible
         to insure interoperability.

   ---------
   New text: (Section 3.3.11)
   ---------
      Cookie: variable size

         This field must contain the exact cookie received in the State
         Cookie parameter from the previous INIT ACK.

         An implementation SHOULD make the cookie as small as possible
         to ensure interoperability.

         Note: A Cookie Echo does NOT contain a State Cookie
         Parameter; instead, the data within the State Cookie's
         Parameter Value becomes the data within the Cookie Echo's
         Chunk Value.  This allows an implementation to change only
         the first two bytes of the State Cookie parameter to become
         a Cookie Echo Chunk.

2.43.3. Solution Description

The new text adds a note that helps clarify that a Cookie Echo chunk is nothing more than the State Cookie parameter with only two bytes modified.

2.44. Partial Chunks

2.44.1. Description of the Problem

Section 6.10 of RFC 2960 [5] uses the notion of 'partial chunks' without defining it.

2.44.2. Text Changes to the Document

--------- Old text: (Section 6.10) --------- Partial chunks MUST NOT be placed in an SCTP packet. --------- New text: (Section 6.10) --------- Partial chunks MUST NOT be placed in an SCTP packet. A partial chunk is a chunk that is not completely contained in the SCTP packet; i.e., the SCTP packet is too short to contain all the bytes of the chunk as indicated by the chunk length.
Top   ToC   RFC4460 - Page 97

2.44.3. Solution Description

The new text adds a definition of 'partial chunks'.

2.45. Non-unicast Addresses

2.45.1. Description of the Problem

Section 8.4 of RFC 2960 [5] forces the OOTB handling to discard all non-unicast addresses. This leaves future use of anycast addresses in question. With the addition of the add-ip feature, SCTP should be able to easily handle anycast INIT s that can be followed, after association setup, with a delete of the anycast address from the association.

2.45.2. Text Changes to the Document

--------- Old text: (Section 8.4) --------- 8.4 Handle "Out of the blue" Packets An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed, i.e., passed the receiver's Adler-32 check (see Section 6.8), but the receiver is not able to identify the association to which this packet belongs. The receiver of an OOTB packet MUST do the following: 1) If the OOTB packet is to or from a non-unicast address, silently discard the packet. Otherwise, --------- New text: (Section 8.4) --------- 8.4. Handle "Out of the Blue" Packets An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed (i.e., passed the receiver's CRC32c check; see Section 6.8), but the receiver is not able to identify the association to which this packet belongs. The receiver of an OOTB packet MUST do the following: 1) If the OOTB packet is to or from a non-unicast address, a receiver SHOULD silently discard the packet. Otherwise,
Top   ToC   RFC4460 - Page 98

2.45.3. Solution Description

The loosening of the wording to a SHOULD will now allow future use of anycast addresses. Note that no changes are made to Section 11.2.4.1, since responding to broadcast addresses could lead to flooding attacks and implementors should pay careful attention to these words.

2.46. Processing of ABORT Chunks

2.46.1. Description of the Problem

Section 3.3.7 of RFC 2960 [5] requires an SCTP endpoint to silently discard ABORT chunks received for associations that do not exist. It is not clear what this means in the COOKIE-WAIT state, for example. Therefore, it was not clear whether an ABORT sent in response to an INIT should be processed or silently discarded.

2.46.2. Text Changes to the Document

--------- Old text: (Section 3.3.7) --------- If an endpoint receives an ABORT with a format error or for an association that doesn't exist, it MUST silently discard it. --------- New text: (Section 3.3.7) --------- If an endpoint receives an ABORT with a format error or no TCB is found, it MUST silently discard it.

2.46.3. Solution Description

It is now clearly stated that an ABORT chunk should be processed whenever a TCB is found.
Top   ToC   RFC4460 - Page 99

2.47. Sending of ABORT Chunks

2.47.1. Description of the Problem

Section 5.1 of RFC 2960 [5] requires that an ABORT chunk be sent in response to an INIT chunk when there is no listening end point. To make port scanning harder, someone might not want these ABORTs to be received by the sender of the INIT chunks. Currently, the only way to enforce this is by using a firewall that discards the packets containing the INIT chunks or the packets containing the ABORT chunks. It is desirable that the same can be done without a middle box.

2.47.2. Text Changes to the Document

--------- Old text: (Section 5.1) --------- If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it MUST respond with an ABORT chunk. --------- New text: (Section 5.1) --------- If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it SHOULD respond with an ABORT chunk.

2.47.3. Solution Description

The requirement of sending ABORT chunks is relaxed such that an implementation can decide not to send ABORT chunks.

2.48. Handling of Supported Address Types Parameter

2.48.1. Description of the Problem

The sender of the INIT chunk can include a 'Supported Address Types' parameter to indicate which address families are supported. It is unclear how an INIT chunk should be processed where the source address of the packet containing the INIT chunk or listed addresses
Top   ToC   RFC4460 - Page 100
   within the INIT chunk indicate that more address types are supported
   than those listed in the 'Supported Address Types' parameter.

2.48.2. Text Changes to the Document

The changes given here already include changes suggested in Section 2.28 of this document. --------- Old text: (Section 5.1.2) --------- IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers. --------- New text: (Section 5.1.2) --------- IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re- initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers. IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT- ACK chunk from its peer, it MUST use all the addresses belonging to the supported address family. The other addresses MAY be ignored. The endpoint SHOULD NOT respond with any kind of error indication. IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported Address Types' parameter either IPv4 or IPv6, but uses the other family for sending the packet containing the INIT chunk, or if it also lists addresses of the other family in the INIT chunk, then the address family that is not listed in the 'Supported Address Types' parameter SHOULD also be considered as supported by the receiver of the INIT chunk. The receiver of the INIT chunk SHOULD NOT respond with any kind of error indication.

2.48.3. Solution Description

It is now clearly described how these Supported Address Types parameters with incorrect data should be handled.
Top   ToC   RFC4460 - Page 101

2.49. Handling of Unexpected Parameters

2.49.1. Description of the Problem

RFC 2960 [5] clearly describes how unknown parameters in the INIT and INIT-ACK chunk should be processed. But it is not described how unexpected parameters should be processed. A parameter is unexpected if it is known and is an optional parameter in either the INIT or INIT-ACK chunk but is received in the chunk for which it is not an optional parameter. For example, the 'Supported Address Types' parameter would be an unexpected parameter if contained in an INIT- ACK chunk.

2.49.2. Text Changes to the Document

--------- Old text: (Section 3.3.2) --------- Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type. --------- New text: (Section 3.3.2) --------- Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type. IMPLEMENTATION NOTE: If an INIT chunk is received with known parameters that are not optional parameters of the INIT chunk then the receiver SHOULD process the INIT chunk and send back an INIT-ACK. The receiver of the INIT chunk MAY bundle an ERROR chunk with the COOKIE-ACK chunk later. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT chunk.
Top   ToC   RFC4460 - Page 102
   ---------
   Old text: (Section 3.3.3)
   ---------

      IMPLEMENTATION NOTE: An implementation MUST be prepared to receive
      a INIT ACK that is quite large (more than 1500 bytes) due to the
      variable size of the state cookie AND the variable address list.
      For example if a responder to the INIT has 1000 IPv4 addresses
      it wishes to send, it would need at least 8,000 bytes to encode
      this in the INIT ACK.

   ---------
   New text: (Section 3.3.3)
   ---------

      IMPLEMENTATION NOTE: An implementation MUST be prepared to receive
      a INIT ACK that is quite large (more than 1500 bytes) due to the
      variable size of the state cookie AND the variable address list.
      For example, if a responder to the INIT has 1000 IPv4 addresses
      it wishes to send, it would need at least 8,000 bytes to encode
      this in the INIT ACK.

      IMPLEMENTATION NOTE: If an INIT-ACK chunk is received with known
      parameters that are not optional parameters of the INIT-ACK
      chunk, then the receiver SHOULD process the INIT-ACK chunk and
      send back a COOKIE-ECHO.  The receiver of the INIT-ACK chunk
      MAY bundle an ERROR chunk with the COOKIE-ECHO chunk.  However,
      restrictive implementations MAY send back an ABORT chunk in
      response to the INIT-ACK chunk.

2.49.3. Solution Description

It is now stated how unexpected parameters should be processed.

2.50. Payload Protocol Identifier

2.50.1. Description of the Problem

The current description of the payload protocol identifier does NOT highlight the fact that the field is NOT necessarily in network byte order.
Top   ToC   RFC4460 - Page 103

2.50.2. Text Changes to the Document

--------- Old text: (Section 3.3.1) --------- Payload Protocol Identifier: 32 bits (unsigned integer) This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities as well as the peer application to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). The value 0 indicates no application identifier is specified by the upper layer for this payload data. --------- New text: (Section 3.3.1) --------- Payload Protocol Identifier: 32 bits (unsigned integer) This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). Note that this field is NOT touched by an SCTP implementation, therefore its byte order is NOT necessarily Big Endian. The upper layer is responsible for any byte order conversions to this field. The value 0 indicates that no application identifier is specified by the upper layer for this payload data.

2.50.3. Solution Description

It is now explicitly stated that the upper layer is responsible for the byte order of this field.
Top   ToC   RFC4460 - Page 104

2.51. Karn's Algorithm

2.51.1. Description of the Problem

The current wording of the use of Karn's algorithm is not descriptive enough to ensure that an implementation in a multi-homed association does not incorrectly mismeasure the RTT.

2.51.2. Text Changes to the Document

--------- Old text: (Section 6.3.1) --------- C5) Karn's algorithm: RTT measurements MUST NOT be made using packets that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the packet or a later instance) --------- New text: (Section 6.3.1) --------- C5) Karn's algorithm: RTT measurements MUST NOT be made using chunks that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the chunk or for a later instance) IMPLEMENTATION NOTE: RTT measurements should only be made using a chunk with TSN r if no chunk with TSN less than or equal to r is retransmitted since r is first sent.

2.51.3. Solution Description

The above clarification adds an implementation note that will provide additional guidance in the application of Karn's algorithm.

2.52. Fast Retransmit Algorithm

2.52.1. Description of the Problem

The original SCTP specification is overly conservative in requiring 4 missing reports before fast retransmitting a segment. TCP uses 3 missing reports or 4 acknowledgements indicating that the same segment was received.
Top   ToC   RFC4460 - Page 105

2.52.2. Text Changes to the Document

--------- Old text: --------- 7.2.4 Fast Retransmit on Gap Reports In the absence of data loss, an endpoint performs delayed acknowledgement. However, whenever an endpoint notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrives carrying data until the hole is filled. 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. --------- New text: --------- 7.2.4. Fast Retransmit on Gap Reports In the absence of data loss, an endpoint performs delayed acknowledgement. However, whenever an endpoint notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrives carrying data until the hole is filled. Whenever an endpoint receives a SACK that indicates that some TSNs are missing, it SHOULD wait for 2 further miss indications (via subsequent SACKs for a total of 3 missing reports) on the same TSNs before taking action with regard to Fast Retransmit.

2.52.3. Solution Description

The above changes will make SCTP and TCP behave similarly in terms of how fast they engage the Fast Retransmission algorithm upon receiving missing reports.

3. Security Considerations

This document should add no additional security risks to SCTP and in fact SHOULD correct some original security flaws within the original document once it is incorporated into a RFC 2960 [5] BIS document.
Top   ToC   RFC4460 - Page 106

4. Acknowledgements

The authors would like to thank the following people who have provided comments and input for this document: Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng, Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann, Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig, Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger, Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar. A special thanks to Mark Allman, who should actually be a co-author for his work on the max-burst, but managed to wiggle out due to a technicality. Also, we would like to acknowledge Lyndon Ong and Phil Conrad for their valuable input and many contributions.

5. IANA Considerations

This document recommends changes for the RFC 2960 [5] BIS document. As such, even though it lists new error cause code, this document in itself does NOT define those new codes. Instead, the BIS document will make the needed changes to RFC 2960 [5] and thus its IANA section will require changes to be made.

6. Normative References

[1] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Caro, A., Shah, K., Iyengar, J., Amer, P., and R. Stewart, "SCTP and TCP Variants: Congestion Control Under Multiple Losses", Technical Report TR2003-04, Computer and Information Sciences Department, University of Delaware, February 2003, <http://www.armandocaro.net/papers>.
Top   ToC   RFC4460 - Page 107
   [4]  Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for
        End-to-end Failover with Transport Layer Multihoming", GLOBECOM,
        November 2004., <http://www.armandocaro.net/papers>.

   [5]  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
        H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
        Paxson, "Stream Control Transmission Protocol", RFC 2960,
        October 2000.

   [6]  Stone, J., Stewart, R., and D. Otis, "Stream Control
        Transmission Protocol (SCTP) Checksum Change", RFC 3309,
        September 2002.
Top   ToC   RFC4460 - Page 108

Authors' Addresses

Randall R. Stewart Cisco Systems, Inc. 4875 Forest Drive Suite 200 Columbia, SC 29206 USA EMail: rrs@cisco.com Ivan Arias-Rodriguez Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland EMail: ivan.arias-rodriguez@nokia.com Kacheong Poon Sun Microsystems, Inc. 3571 N. First St. San Jose, CA 95134 USA EMail: kacheong.poon@sun.com Armando L. Caro Jr. BBN Technologies 10 Moulton St. Cambridge, MA 02138 EMail: acaro@bbn.com URI: http://www.armandocaro.net Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany EMail: tuexen@fh-muenster.de
Top   ToC   RFC4460 - Page 109
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).