Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4960

Stream Control Transmission Protocol

Pages: 152
Obsoletes:  29603309
Obsoleted by:  9260
Updated by:  6096633570538899
Part 4 of 7 – Pages 65 to 83
First   Prev   Next

Top   ToC   RFC4960 - Page 65   prevText

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.
Top   ToC   RFC4960 - Page 66

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
Top   ToC   RFC4960 - Page 67
   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,
Top   ToC   RFC4960 - Page 68
       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:
Top   ToC   RFC4960 - Page 69
      -  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):
Top   ToC   RFC4960 - Page 70
   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
Top   ToC   RFC4960 - Page 71

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.
Top   ToC   RFC4960 - Page 72

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.
Top   ToC   RFC4960 - Page 73
   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.
Top   ToC   RFC4960 - Page 74
   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.
Top   ToC   RFC4960 - Page 75
                 +--------------------------+
                 |      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.
Top   ToC   RFC4960 - Page 76
   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.
Top   ToC   RFC4960 - Page 77
   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.
Top   ToC   RFC4960 - Page 78
   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.
Top   ToC   RFC4960 - Page 79
   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.
Top   ToC   RFC4960 - Page 80
   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.
Top   ToC   RFC4960 - Page 81
   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
Top   ToC   RFC4960 - Page 82
   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.
Top   ToC   RFC4960 - Page 83
       iv) If the Cumulative TSN Ack matches or exceeds the Fast
           Recovery exitpoint (Section 7.2.4), Fast Recovery is exited.



(page 83 continued on part 5)

Next Section