5.2.  Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and
      COOKIE ACK

   During the life time of an association (in one of the possible
   states), an endpoint may receive from its peer endpoint one of the
   setup chunks (INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK).  The
   receiver shall treat such a setup chunk as a duplicate and process it
   as described in this section.

   Note: An endpoint will not receive the chunk unless the chunk was
   sent to an SCTP transport address and is from an SCTP transport
   address associated with this endpoint.  Therefore, the endpoint
   processes such a chunk as part of its current association.

   The following scenarios can cause duplicated or unexpected chunks:

   A) The peer has crashed without being detected, restarted itself, and
      sent out a new INIT chunk trying to restore the association,

   B) Both sides are trying to initialize the association at about the
      same time,

   C) The chunk is from a stale packet that was used to establish the
      present association or a past association that is no longer in
      existence,

   D) The chunk is a false packet generated by an attacker, or

   E) The peer never received the COOKIE ACK and is retransmitting its
      COOKIE ECHO.

   The rules in the following sections shall be applied in order to
   identify and correctly handle these cases.

5.2.1.  INIT Received in COOKIE-WAIT or COOKIE-ECHOED State (Item B)

   This usually indicates an initialization collision, i.e., each
   endpoint is attempting, at about the same time, to establish an
   association with the other endpoint.

   Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
   respond with an INIT ACK using the same parameters it sent in its
   original INIT chunk (including its Initiate Tag, unchanged).  When
   responding, the endpoint MUST send the INIT ACK back to the same
   address that the original INIT (sent by this endpoint) was sent.

   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 Initiate Tag, unchanged), provided
   that no NEW address has been added to the forming association.  If
   the INIT message indicates that a new address has been added to the
   association, then the entire INIT MUST be discarded, and NO changes
   should be made to the existing association.  An ABORT SHOULD be sent
   in response that MAY include the error 'Restart of an association
   with new addresses'.  The error SHOULD list the addresses that were
   added to the restarting association.

   When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with
   an INIT ACK, the original parameters are combined with those from the
   newly received INIT chunk.  The endpoint shall also generate a State
   Cookie with the INIT ACK.  The endpoint uses the parameters sent in
   its INIT to calculate the State Cookie.

   After that, the endpoint MUST NOT change its state, the T1-init timer
   shall be left running, and the corresponding TCB MUST NOT be
   destroyed.  The normal procedures for handling State Cookies when a
   TCB exists will resolve the duplicate INITs to a single association.

   For an endpoint that is in the COOKIE-ECHOED state, it MUST populate
   its Tie-Tags within both the association TCB and inside the State
   Cookie (see Section 5.2.2 for a description of the Tie-Tags).

5.2.2.  Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
        COOKIE-WAIT, and SHUTDOWN-ACK-SENT

   Unless otherwise stated, upon receipt of an unexpected INIT for this
   association, the endpoint shall generate an INIT ACK with a State
   Cookie.  Before responding, the endpoint MUST check to see if the
   unexpected INIT adds new addresses to the association.  If new
   addresses are added to the association, the endpoint MUST respond
   with an ABORT, copying the 'Initiate 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 Tie-Tags to a reserved place within
   the State Cookie and the association's TCB.  We shall refer to these
   locations inside the cookie as the Peer's-Tie-Tag and the Local-Tie-
   Tag.  We will refer to the copy within an association's TCB as the
   Local Tag and Peer's Tag.  The outbound SCTP packet containing this
   INIT ACK MUST carry a Verification Tag value equal to the Initiate
   Tag found in the unexpected INIT.  And the INIT ACK MUST contain a
   new Initiate 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).

5.2.3.  Unexpected INIT ACK

   If an INIT ACK is received by an endpoint in any state other than the
   COOKIE-WAIT state, the endpoint should discard the INIT ACK chunk.
   An unexpected INIT ACK usually indicates the processing of an old or
   duplicated INIT chunk.

5.2.4.  Handle a COOKIE ECHO when a TCB Exists

   When a COOKIE ECHO chunk is received by an endpoint in any state for
   an existing association (i.e., not in the CLOSED state) the following
   rules shall be applied:

   1)  Compute a MAC as described in step 1 of Section 5.1.5,

   2)  Authenticate the State Cookie as described in step 2 of Section
       5.1.5 (this is case C or D above).

   3)  Compare the timestamp in the State Cookie to the current time.
       If the State Cookie is older than the lifespan carried in the
       State Cookie and the Verification Tags contained in the State
       Cookie do not match the current association's Verification Tags,

       the packet, including the COOKIE ECHO and any DATA chunks, should
       be discarded.  The endpoint also MUST transmit an ERROR chunk
       with a "Stale Cookie" error cause to the peer endpoint (this is
       case C or D in Section 5.2).

       If both Verification Tags in the State Cookie match the
       Verification Tags of the current association, consider the State
       Cookie valid (this is case E in Section 5.2) even if the lifespan
       is exceeded.

   4)  If the State Cookie proves to be valid, unpack the TCB into a
       temporary TCB.

   5)  Refer to Table 2 to determine the correct action to be taken.

+------------+------------+---------------+--------------+-------------+
|  Local Tag | Peer's Tag | Local-Tie-Tag |Peer's-Tie-Tag|   Action/   |
|            |            |               |              | Description |
+------------+------------+---------------+--------------+-------------+
|    X       |     X      |      M        |      M       |     (A)     |
+------------+------------+---------------+--------------+-------------+
|    M       |     X      |      A        |      A       |     (B)     |
+------------+------------+---------------+--------------+-------------+
|    M       |     0      |      A        |      A       |     (B)     |
+------------+------------+---------------+--------------+-------------+
|    X       |     M      |      0        |      0       |     (C)     |
+------------+------------+---------------+--------------+-------------+
|    M       |     M      |      A        |      A       |     (D)     |
+======================================================================+
|       Table 2: Handling of a COOKIE ECHO when a TCB Exists           |
+======================================================================+

   Legend:

      X - Tag does not match the existing TCB.
      M - Tag matches the existing TCB.
      0 - No Tie-Tag in cookie (unknown).
      A - All cases, i.e., M, X, or 0.

   Note: For any case not shown in Table 2, the cookie should be
   silently discarded.

   Action

   A) In this case, the peer may have restarted.  When the endpoint
      recognizes this potential 'restart', the existing session is
      treated the same as if it received an ABORT followed by a new
      COOKIE ECHO with the following exceptions:

      -  Any SCTP DATA chunks MAY be retained (this is an
         implementation-specific option).

      -  A notification of RESTART SHOULD be sent to the ULP instead of
         a "COMMUNICATION LOST" notification.

      All the congestion control parameters (e.g., cwnd, ssthresh)
      related to this peer MUST be reset to their initial values (see
      Section 6.2.1).

      After this, the endpoint shall enter the ESTABLISHED state.

      If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes
      that the peer has restarted (Action A), it MUST NOT set up a new
      association but instead resend the SHUTDOWN ACK and send an ERROR
      chunk with a "Cookie Received While Shutting Down" error cause to
      its peer.

   B) In this case, both sides may be attempting to start an association
      at about the same time, but the peer endpoint started its INIT
      after responding to the local endpoint's INIT.  Thus, it may have
      picked a new Verification Tag, not being aware of the previous tag
      it had sent this endpoint.  The endpoint should stay in or enter
      the ESTABLISHED state, but it MUST update its peer's Verification
      Tag from the State Cookie, stop any init or cookie timers that may
      be running, and send a COOKIE ACK.

   C) In this case, the local endpoint's cookie has arrived late.
      Before it arrived, the local endpoint sent an INIT and received an
      INIT ACK and finally sent a COOKIE ECHO with the peer's same tag
      but a new tag of its own.  The cookie should be silently
      discarded.  The endpoint SHOULD NOT change states and should leave
      any timers running.

   D) When both local and remote tags match, the endpoint should enter
      the ESTABLISHED state, if it is in the COOKIE-ECHOED state.  It
      should stop any cookie timer that may be running and send a COOKIE
      ACK.

   Note: The "peer's Verification Tag" is the tag received in the
   Initiate Tag field of the INIT or INIT ACK chunk.

5.2.4.1.  An Example of a Association Restart

   In the following example, "A" initiates the association after a
   restart has occurred.  Endpoint "Z" had no knowledge of the restart
   until the exchange (i.e., Heartbeats had not yet detected the failure
   of "A") (assuming no bundling or fragmentation occurs):

   Endpoint A                                          Endpoint Z
   <-------------- Association is established---------------------->
   Tag=Tag_A                                             Tag=Tag_Z
   <--------------------------------------------------------------->
   {A crashes and restarts}
   {app sets up a association with Z}
   (build TCB)
   INIT [I-Tag=Tag_A'
         & other info]  --------\
   (Start T1-init timer)         \
   (Enter COOKIE-WAIT state)      \---> (find an existing TCB
                                         compose temp TCB and Cookie_Z
                                         with Tie-Tags to previous
                                         association)
                                   /--- INIT ACK [Veri Tag=Tag_A',
                                  /               I-Tag=Tag_Z',
   (Cancel T1-init timer) <------/                Cookie_Z[TieTags=
                                                  Tag_A,Tag_Z
                                                   & other info]
                                        (destroy temp TCB,leave original
                                         in place)
   COOKIE ECHO [Veri=Tag_Z',
                Cookie_Z
                Tie=Tag_A,
                Tag_Z]----------\
   (Start T1-init timer)         \
   (Enter COOKIE-ECHOED state)    \---> (Find existing association,
                                         Tie-Tags match old tags,
                                         Tags do not match, i.e.,
                                         case X X M M above,
                                         Announce Restart to ULP
                                         and reset association).
                                  /---- COOKIE ACK
   (Cancel T1-init timer, <------/
    Enter ESTABLISHED state)
   {app sends 1st user data; strm 0}
   DATA [TSN=initial TSN_A
       Strm=0,Seq=0 & user data]--\
   (Start T3-rtx timer)            \
                                    \->
                                 /--- SACK [TSN Ack=init TSN_A,Block=0]
   (Cancel T3-rtx timer) <------/

                        Figure 5: A Restart Example

5.2.5.  Handle Duplicate COOKIE-ACK.

   At any state other than COOKIE-ECHOED, an endpoint should silently
   discard a received COOKIE ACK chunk.

5.2.6.  Handle Stale COOKIE Error

   Receipt of an ERROR chunk with a "Stale Cookie" error cause indicates
   one of a number of possible events:

   A) The association failed to completely setup before the State Cookie
      issued by the sender was processed.

   B) An old State Cookie was processed after setup completed.

   C) An old State Cookie is received from someone that the receiver is
      not interested in having an association with and the ABORT chunk
      was lost.

   When processing an ERROR chunk with a "Stale Cookie" error cause an
   endpoint should first examine if an association is in the process of
   being set up, i.e., the association is in the COOKIE-ECHOED state.
   In all cases, if the association is not in the COOKIE-ECHOED state,
   the ERROR chunk should be silently discarded.

   If the association is in the COOKIE-ECHOED state, the endpoint may
   elect one of the following three alternatives.

   1)  Send a new INIT chunk to the endpoint to generate a new State
       Cookie and reattempt the setup procedure.

   2)  Discard the TCB and report to the upper layer the inability to
       set up the association.

   3)  Send a new INIT chunk to the endpoint, adding a Cookie
       Preservative parameter requesting an extension to the life time
       of the State Cookie.  When calculating the time extension, an
       implementation SHOULD use the RTT information measured based on
       the previous COOKIE ECHO / ERROR exchange, and should add no more
       than 1 second beyond the measured RTT, due to long State Cookie
       life times making the endpoint more subject to a replay attack.

5.3.  Other Initialization Issues

5.3.1.  Selection of Tag Value

   Initiate Tag values should be selected from the range of 1 to 2**32 -
   1.  It is very important that the Initiate Tag value be randomized to
   help protect against "man in the middle" and "sequence number"
   attacks.  The methods described in [RFC4086] can be used for the
   Initiate Tag randomization.  Careful selection of Initiate Tags is
   also necessary to prevent old duplicate packets from previous
   associations being mistakenly processed as belonging to the current
   association.

   Moreover, the Verification Tag value used by either endpoint in a
   given association MUST NOT change during the life time of an
   association.  A new Verification Tag value MUST be used each time the
   endpoint tears down and then reestablishes an association to the same
   peer.

5.4.  Path Verification

   During association establishment, the two peers exchange a list of
   addresses.  In the predominant case, these lists accurately represent
   the addresses owned by each peer.  However, it is possible that a
   misbehaving peer may supply addresses that it does not own.  To
   prevent this, the following rules are applied to all addresses of the
   new association:

   1)  Any address passed to the sender of the INIT by its upper layer
      is automatically considered to be CONFIRMED.

   2)  For the receiver of the COOKIE ECHO, the only CONFIRMED address
      is the one to which the INIT-ACK was sent.

   3)  All other addresses not covered by rules 1 and 2 are considered
      UNCONFIRMED and are subject to probing for verification.

   To probe an address for verification, an endpoint will send
   HEARTBEATs including a 64-bit random nonce and a path indicator (to
   identify the address that the HEARTBEAT is sent to) within the
   HEARTBEAT parameter.

   Upon receipt of the HEARTBEAT ACK, a verification is made that the
   nonce included in the HEARTBEAT parameter is the one sent to the
   address indicated inside the HEARTBEAT parameter.  When this match
   occurs, the address that the original HEARTBEAT was sent to is now
   considered CONFIRMED and available for normal data transfer.

   These probing procedures are started when an association moves to the
   ESTABLISHED state and are ended when all paths are confirmed.

   In each RTO, a probe may be sent on an active UNCONFIRMED path in an
   attempt to move it to the CONFIRMED state.  If during this probing
   the path becomes inactive, this rate is lowered to the normal
   HEARTBEAT rate.  At the expiration of the RTO timer, the error
   counter of any path that was probed but not CONFIRMED is incremented
   by one and subjected to path failure detection, as defined in Section
   8.2.  When probing UNCONFIRMED addresses, however, the association
   overall error count is NOT incremented.

   The number of HEARTBEATS sent at each RTO SHOULD be limited by the
   HB.Max.Burst parameter.  It is an implementation decision as to how
   to distribute HEARTBEATS to the peer's addresses for path
   verification.

   Whenever a path is confirmed, an indication MAY be given to the upper
   layer.

   An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with
   the following exceptions:

   -  A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED
      address.

   -  A HEARTBEAT ACK MAY be sent to an UNCONFIRMED address.

   -  A COOKIE ACK MAY be sent to an UNCONFIRMED address, but it MUST be
      bundled with a HEARTBEAT including a nonce.  An implementation
      that does NOT support bundling MUST NOT send a COOKIE ACK to an
      UNCONFIRMED address.

   -  A COOKIE ECHO MAY be sent to an UNCONFIRMED address, but it MUST
      be bundled with a HEARTBEAT including a nonce, and the packet MUST
      NOT exceed the path MTU.  If the implementation does NOT support
      bundling or if the bundled COOKIE ECHO plus HEARTBEAT (including
      nonce) would exceed the path MTU, then the implementation MUST NOT
      send a COOKIE ECHO to an UNCONFIRMED address.

6.  User Data Transfer

   Data transmission MUST only happen in the ESTABLISHED, SHUTDOWN-
   PENDING, and SHUTDOWN-RECEIVED states.  The only exception to this is
   that DATA chunks are allowed to be bundled with an outbound COOKIE
   ECHO chunk when in the COOKIE-WAIT state.

   DATA chunks MUST only be received according to the rules below in
   ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-SENT.  A DATA chunk
   received in CLOSED is out of the blue and SHOULD be handled per
   Section 8.4.  A DATA chunk received in any other state SHOULD be
   discarded.

   A SACK MUST be processed in ESTABLISHED, SHUTDOWN-PENDING, and
   SHUTDOWN-RECEIVED.  An incoming SACK MAY be processed in COOKIE-
   ECHOED.  A SACK in the CLOSED state is out of the blue and SHOULD be
   processed according to the rules in Section 8.4.  A SACK chunk
   received in any other state SHOULD be discarded.

   An SCTP receiver MUST be able to receive a minimum of 1500 bytes in
   one SCTP packet.  This means that an SCTP endpoint MUST NOT indicate
   less than 1500 bytes in its initial a_rwnd sent in the INIT or INIT
   ACK.

   For transmission efficiency, SCTP defines mechanisms for bundling of
   small user messages and fragmentation of large user messages.  The
   following diagram depicts the flow of user messages through SCTP.

   In this section, the term "data sender" refers to the endpoint that
   transmits a DATA chunk and the term "data receiver" refers to the
   endpoint that receives a DATA chunk.  A data receiver will transmit
   SACK chunks.

                 +--------------------------+
                 |      User Messages       |
                 +--------------------------+
       SCTP user        ^  |
      ==================|==|=======================================
                        |  v (1)
             +------------------+    +--------------------+
             | SCTP DATA Chunks |    |SCTP Control Chunks |
             +------------------+    +--------------------+
                        ^  |             ^  |
                        |  v (2)         |  v (2)
                     +--------------------------+
                     |      SCTP packets        |
                     +--------------------------+
       SCTP                      ^  |
      ===========================|==|===========================
                                 |  v
             Connectionless Packet Transfer Service (e.g., IP)

   Notes:

      1) When converting user messages into DATA chunks, an endpoint
         will fragment user messages larger than the current association
         path MTU into multiple DATA chunks.  The data receiver will
         normally reassemble the fragmented message from DATA chunks
         before delivery to the user (see Section 6.9 for details).

      2) Multiple DATA and control chunks may be bundled by the sender
         into a single SCTP packet for transmission, as long as the
         final size of the packet does not exceed the current path MTU.
         The receiver will unbundle the packet back into the original
         chunks.  Control chunks MUST come before DATA chunks in the
         packet.

                Figure 6: Illustration of User Data Transfer

   The fragmentation and bundling mechanisms, as detailed in Section 6.9
   and Section 6.10, are OPTIONAL to implement by the data sender, but
   they MUST be implemented by the data receiver, i.e., an endpoint MUST
   properly receive and process bundled or fragmented data.

6.1.  Transmission of DATA Chunks

   This document is specified as if there is a single retransmission
   timer per destination transport address, but implementations MAY have
   a retransmission timer for each DATA chunk.

   The following general rules MUST be applied by the data sender for
   transmission and/or retransmission of outbound DATA chunks:

   A) At any given time, the data sender MUST NOT transmit new data to
      any destination transport address if its peer's rwnd indicates
      that the peer has no buffer space (i.e., rwnd is 0; see Section
      6.2.1).  However, regardless of the value of rwnd (including if it
      is 0), the data sender can always have one DATA chunk in flight to
      the receiver if allowed by cwnd (see rule B, below).  This rule
      allows the sender to probe for a change in rwnd that the sender
      missed due to the SACK's having been lost in transit from the data
      receiver to the data sender.

      When the receiver's advertised window is zero, this probe is
      called a zero window probe.  Note that a zero window probe SHOULD
      only be sent when all outstanding DATA chunks have been
      cumulatively acknowledged and no DATA chunks are in flight.  Zero
      window probing MUST be supported.

      If the sender continues to receive new packets from the receiver
      while doing zero window probing, the unacknowledged window probes
      should not increment the error counter for the association or any
      destination transport address.  This is because the receiver MAY
      keep its window closed for an indefinite time.  Refer to Section
      6.2 on the receiver behavior when it advertises a zero window.
      The sender SHOULD send the first zero window probe after 1 RTO
      when it detects that the receiver has closed its window and SHOULD
      increase the probe interval exponentially afterwards.  Also note
      that the cwnd SHOULD be adjusted according to Section 7.2.1.  Zero
      window probing does not affect the calculation of cwnd.

      The sender MUST also have an algorithm for sending new DATA chunks
      to avoid silly window syndrome (SWS) as described in [RFC0813].
      The algorithm can be similar to the one described in Section
      4.2.3.4 of [RFC1122].

      However, regardless of the value of rwnd (including if it is 0),
      the data sender can always have one DATA chunk in flight to the
      receiver if allowed by cwnd (see rule B below).  This rule allows
      the sender to probe for a change in rwnd that the sender missed
      due to the SACK having been lost in transit from the data receiver
      to the data sender.

   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.

   C) When the time comes for the sender to transmit, before sending new
      DATA chunks, the sender MUST first transmit any outstanding DATA
      chunks that are marked for retransmission (limited by the current
      cwnd).

   D) When the time comes for the sender to transmit new DATA chunks,
      the protocol parameter Max.Burst SHOULD be used to limit the
      number of packets sent.  The limit MAY be applied by adjusting
      cwnd as follows:

      if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +
      Max.Burst*MTU

      Or it MAY be applied by strictly limiting the number of packets
      emitted by the output routine.

   E) Then, the sender can send out as many new DATA chunks as rule A
      and rule B allow.

   Multiple DATA chunks committed for transmission MAY be bundled in a
   single packet.  Furthermore, DATA chunks being retransmitted MAY be
   bundled with new DATA chunks, as long as the resulting packet size
   does not exceed the path MTU.  A ULP may request that no bundling is
   performed, but this should only turn off any delays that an SCTP
   implementation may be using to increase bundling efficiency.  It does
   not in itself stop all bundling from occurring (i.e., in case of
   congestion or retransmission).

   Before an endpoint transmits a DATA chunk, if any received DATA
   chunks have not been acknowledged (e.g., due to delayed ack), the
   sender should create a SACK and bundle it with the outbound DATA
   chunk, as long as the size of the final SCTP packet does not exceed
   the current MTU.  See Section 6.2.

   IMPLEMENTATION NOTE: When the window is full (i.e., transmission is
   disallowed by rule A and/or rule B), the sender MAY still accept send
   requests from its upper layer, but MUST transmit no more DATA chunks
   until some or all of the outstanding DATA chunks are acknowledged and
   transmission is allowed by rule A and rule B again.

   Whenever a transmission or retransmission is made to any address, if
   the T3-rtx timer of that address is not currently running, the sender
   MUST start that timer.  If the timer for that address is already
   running, the sender MUST restart the timer if the earliest (i.e.,
   lowest TSN) outstanding DATA chunk sent to that address is being
   retransmitted.  Otherwise, the data sender MUST NOT restart the
   timer.

   When starting or restarting the T3-rtx timer, the timer value must be
   adjusted according to the timer rules defined in Sections 6.3.2 and
   6.3.3.

   Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
   1 above the beginning TSN of the current send window.

6.2.  Acknowledgement on Reception of DATA Chunks

   The SCTP endpoint MUST always acknowledge the reception of each valid
   DATA chunk when the DATA chunk received is inside its receive window.

   When the receiver's advertised window is 0, the receiver MUST drop
   any new incoming DATA chunk with a TSN larger than the largest TSN
   received so far.  If the new incoming DATA chunk holds a TSN value
   less than the largest TSN received so far, then the receiver SHOULD
   drop the largest TSN held for reordering and accept the new incoming
   DATA chunk.  In either case, if such a DATA chunk is dropped, the
   receiver MUST immediately send back a SACK with the current receive
   window showing only DATA chunks received and accepted so far.  The
   dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
   not accepted.  The receiver MUST also have an algorithm for
   advertising its receive window to avoid receiver silly window
   syndrome (SWS), as described in [RFC0813].  The algorithm can be
   similar to the one described in Section 4.2.3.3 of [RFC1122].

   The guidelines on delayed acknowledgement algorithm specified in
   Section 4.2 of [RFC2581] SHOULD be followed.  Specifically, an
   acknowledgement SHOULD be generated for at least every second packet
   (not every second DATA chunk) received, and SHOULD be generated
   within 200 ms of the arrival of any unacknowledged DATA chunk.  In
   some situations, it may be beneficial for an SCTP transmitter to be
   more conservative than the algorithms detailed in this document
   allow.  However, an SCTP transmitter MUST NOT be more aggressive than
   the following algorithms allow.

   An SCTP receiver MUST NOT generate more than one SACK for every
   incoming packet, other than to update the offered window as the
   receiving application consumes new data.

   IMPLEMENTATION NOTE: The maximum delay for generating an
   acknowledgement may be configured by the SCTP administrator, either
   statically or dynamically, in order to meet the specific timing
   requirement of the protocol being carried.

   An implementation MUST NOT allow the maximum delay to be configured
   to be more than 500 ms.  In other words, an implementation MAY lower
   this value below 500 ms but MUST NOT raise it above 500 ms.

   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 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.

   Note: The SHUTDOWN chunk does not contain Gap Ack Block fields.
   Therefore, the endpoint should use a SACK instead of the SHUTDOWN
   chunk to acknowledge DATA chunks received out of order.

   When a packet arrives with duplicate DATA chunk(s) and with no new
   DATA chunk(s), the endpoint MUST immediately send a SACK with no
   delay.  If a packet arrives with duplicate DATA chunk(s) bundled with
   new DATA chunks, the endpoint MAY immediately send a SACK.  Normally,
   receipt of duplicate DATA chunks will occur when the original SACK
   chunk was lost and the peer's RTO has expired.  The duplicate TSN
   number(s) SHOULD be reported in the SACK as duplicate.

   When an endpoint receives a SACK, it MAY use the duplicate TSN
   information to determine if SACK loss is occurring.  Further use of
   this data is for future study.

   The data receiver is responsible for maintaining its receive buffers.
   The data receiver SHOULD notify the data sender in a timely manner of
   changes in its ability to receive data.  How an implementation
   manages its receive buffers is dependent on many factors (e.g.,
   operating system, memory management system, amount of memory, etc.).
   However, the data sender strategy defined in Section 6.2.1 is based
   on the assumption of receiver operation similar to the following:

   A) At initialization of the association, the endpoint tells the peer
      how much receive buffer space it has allocated to the association
      in the INIT or INIT ACK.  The endpoint sets a_rwnd to this value.

   B) As DATA chunks are received and buffered, decrement a_rwnd by the
      number of bytes received and buffered.  This is, in effect,
      closing rwnd at the data sender and restricting the amount of data
      it can transmit.

   C) As DATA chunks are delivered to the ULP and released from the
      receive buffers, increment a_rwnd by the number of bytes delivered
      to the upper layer.  This is, in effect, opening up rwnd on the
      data sender and allowing it to send more data.  The data receiver
      SHOULD NOT increment a_rwnd unless it has released bytes from its
      receive buffer.  For example, if the receiver is holding
      fragmented DATA chunks in a reassembly queue, it should not
      increment a_rwnd.

   D) When sending a SACK, the data receiver SHOULD place the current
      value of a_rwnd into the a_rwnd field.  The data receiver SHOULD
      take into account that the data sender will not retransmit DATA
      chunks that are acked via the Cumulative TSN Ack (i.e., will drop
      from its retransmit queue).

   Under certain circumstances, the data receiver may need to drop DATA
   chunks that it has received but hasn't released from its receive
   buffers (i.e., delivered to the ULP).  These DATA chunks may have
   been acked in Gap Ack Blocks.  For example, the data receiver may be
   holding data in its receive buffers while reassembling a fragmented
   user message from its peer when it runs out of receive buffer space.
   It may drop these DATA chunks even though it has acknowledged them in
   Gap Ack Blocks.  If a data receiver drops DATA chunks, it MUST NOT
   include them in Gap Ack Blocks in subsequent SACKs until they are
   received again via retransmission.  In addition, the endpoint should
   take into account the dropped data when calculating its a_rwnd.

   An endpoint SHOULD NOT revoke a SACK and discard data.  Only in
   extreme circumstances should an endpoint use this procedure (such as
   out of buffer space).  The data receiver should take into account
   that dropping data that has been acked in Gap Ack Blocks can result
   in suboptimal retransmission strategies in the data sender and thus
   in suboptimal performance.

   The following example illustrates the use of delayed
   acknowledgements:

    Endpoint A                                      Endpoint Z

    {App sends 3 messages; strm 0}
    DATA [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
    (Start T3-rtx timer)

    DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack)
                                  /------- SACK [TSN Ack=8,block=0]
    (cancel T3-rtx timer)  <-----/

    DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed)
    (Start T3-rtx timer)
                                           ...
                                           {App sends 1 message; strm 1}
                                           (bundle SACK with DATA)
                                    /----- SACK [TSN Ack=9,block=0] \
                                   /         DATA [TSN=6,Strm=1,Seq=2]
    (cancel T3-rtx timer)  <------/        (Start T3-rtx timer)

    (ack delayed)
    (send ack)
    SACK [TSN Ack=6,block=0] -------------> (cancel T3-rtx timer)

           Figure 7:  Delayed Acknowledgement Example

   If an endpoint receives a DATA chunk with no user data (i.e., the
   Length field is set to 16), it MUST send an ABORT with error cause
   set to "No User Data".

   An endpoint SHOULD NOT send a DATA chunk with no user data part.

6.2.1.  Processing a Received SACK

   Each SACK an endpoint receives contains an a_rwnd value.  This value
   represents the amount of buffer space the data receiver, at the time
   of transmitting the SACK, has left of its total receive buffer space
   (as specified in the INIT/INIT ACK).  Using a_rwnd, Cumulative TSN
   Ack, and Gap Ack Blocks, the data sender can develop a representation
   of the peer's receive buffer space.

   One of the problems the data sender must take into account when
   processing a SACK is that a SACK can be received out of order.  That
   is, a SACK sent by the data receiver can pass an earlier SACK and be
   received first by the data sender.  If a SACK is received out of

   order, the data sender can develop an incorrect view of the peer's
   receive buffer space.

   Since there is no explicit identifier that can be used to detect
   out-of-order SACKs, the data sender must use heuristics to determine
   if a SACK is new.

   An endpoint SHOULD use the following rules to calculate the rwnd,
   using the a_rwnd value, the Cumulative TSN Ack, and Gap Ack Blocks in
   a received SACK.

   A) At the establishment of the association, the endpoint initializes
      the rwnd to the Advertised Receiver Window Credit (a_rwnd) the
      peer specified in the INIT or INIT ACK.

   B) Any time a DATA chunk is transmitted (or retransmitted) to a peer,
      the endpoint subtracts the data size of the chunk from the rwnd of
      that peer.

   C) Any time a DATA chunk is marked for retransmission, either via
      T3-rtx timer expiration (Section 6.3.3) or via Fast Retransmit
      (Section 7.2.4), add the data size of those chunks to the rwnd.

      Note: If the implementation is maintaining a timer on each DATA
      chunk, then only DATA chunks whose timer expired would be marked
      for retransmission.

   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.