chunk. Subsequent acknowledgements should be done as described in
Section 6.2.
When the TCB is created, each endpoint MUST set its internal
Cumulative TSN Ack Point to the value of its transmitted Initial TSN
minus one.
IMPLEMENTATION NOTE: The IP addresses and SCTP port are generally
used as the key to find the TCB within an SCTP instance.
5.1.1 Handle Stream Parameters
In the INIT and INIT ACK chunks, the sender of the chunk shall
indicate the number of outbound streams (OS) it wishes to have in the
association, as well as the maximum inbound streams (MIS) it will
accept from the other endpoint.
After receiving the stream configuration information from the other
side, each endpoint shall perform the following check: If the peer's
MIS is less than the endpoint's OS, meaning that the peer is
incapable of supporting all the outbound streams the endpoint wants
to configure, the endpoint MUST either use MIS outbound streams, or
abort the association and report to its upper layer the resources
shortage at its peer.
After the association is initialized, the valid outbound stream
identifier range for either endpoint shall be 0 to min(local OS,
remote MIS)-1.
5.1.2 Handle Address Parameters
During the association initialization, an endpoint shall use the
following rules to discover and collect the destination transport
address(es) of its peer.
A) If there are no address parameters present in the received INIT or
INIT ACK chunk, the endpoint shall take the source IP address from
which the chunk arrives and record it, in combination with the
SCTP source port number, as the only destination transport address
for this peer.
B) If there is a Host Name parameter present in the received INIT or
INIT ACK chunk, the endpoint shall resolve that host name to a
list of IP address(es) and derive the transport address(es) of
this peer by combining the resolved IP address(es) with the SCTP
source port.
The endpoint MUST ignore any other IP address parameters if they
are also present in the received INIT or INIT ACK chunk.
The time at which the receiver of an INIT resolves the host name
has potential security implications to SCTP. If the receiver of
an INIT resolves the host name upon the reception of the chunk,
and the mechanism the receiver uses to resolve the host name
involves potential long delay (e.g. DNS query), the receiver may
open itself up to resource attacks for the period of time while it
is waiting for the name resolution results before it can build the
State Cookie and release local resources.
Therefore, in cases where the name translation involves potential
long delay, the receiver of the INIT MUST postpone the name
resolution till the reception of the COOKIE ECHO chunk from the
peer. In such a case, the receiver of the INIT SHOULD build the
State Cookie using the received Host Name (instead of destination
transport addresses) and send the INIT ACK to the source IP
address from which the INIT was received.
The receiver of an INIT ACK shall always immediately attempt to
resolve the name upon the reception of the chunk.
The receiver of the INIT or INIT ACK MUST NOT send user data
(piggy-backed or stand-alone) to its peer until the host name is
successfully resolved.
If the name resolution is not successful, the endpoint MUST
immediately send an ABORT with "Unresolvable Address" error cause
to its peer. The ABORT shall be sent to the source IP address
from which the last peer packet was received.
C) If there are only IPv4/IPv6 addresses present in the received INIT
or INIT ACK chunk, the receiver shall derive and record all the
transport address(es) from the received chunk AND the source IP
address that sent the INIT or INIT ACK. The transport address(es)
are derived by the combination of SCTP source port (from the
common header) and the IP address parameter(s) carried in the INIT
or INIT ACK chunk and the source IP address of the IP datagram.
The receiver should use only these transport addresses as
destination transport addresses when sending subsequent packets to
its peer.
IMPLEMENTATION NOTE: In some cases (e.g., when the implementation
doesn't control the source IP address that is used for
transmitting), an endpoint might need to include in its INIT or
INIT ACK all possible IP addresses from which packets to the peer
could be transmitted.
After all transport addresses are derived from the INIT or INIT ACK
chunk using the above rules, the endpoint shall select one of the
transport addresses as the initial primary path.
Note: The INIT-ACK MUST be sent to the source address of the INIT.
The sender of INIT may include a 'Supported Address Types' parameter
in the INIT to indicate what types of address are acceptable. When
this parameter is present, the receiver of INIT (initiatee) MUST
either use one of the address types indicated in the Supported
Address Types parameter when responding to the INIT, or abort the
association with an "Unresolvable Address" error cause if it is
unwilling or incapable of using any of the address types indicated by
its peer.
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.
5.1.3 Generating State Cookie
When sending an INIT ACK as a response to an INIT chunk, the sender
of INIT ACK creates a State Cookie and sends it in the State Cookie
parameter of the INIT ACK. Inside this State Cookie, the sender
should include a MAC (see [RFC2104] for an example), a time stamp on
when the State Cookie is created, and the lifespan of the State
Cookie, along with all the information necessary for it to establish
the association.
The following steps SHOULD be taken to generate the State Cookie:
1) Create an association TCB using information from both the received
INIT and the outgoing INIT ACK chunk,
2) In the TCB, set the creation time to the current time of day, and
the lifespan to the protocol parameter 'Valid.Cookie.Life',
3) From the TCB, identify and collect the minimal subset of
information needed to re-create the TCB, and generate a MAC using
this subset of information and a secret key (see [RFC2104] for an
example of generating a MAC), and
4) Generate the State Cookie by combining this subset of information
and the resultant MAC.
After sending the INIT ACK with the State Cookie parameter, the
sender SHOULD delete the TCB and any other local resource related to
the new association, so as to prevent resource attacks.
The hashing method used to generate the MAC is strictly a private
matter for the receiver of the INIT chunk. The use of a MAC is
mandatory to prevent denial of service attacks. The secret key
SHOULD be random ([RFC1750] provides some information on randomness
guidelines); it SHOULD be changed reasonably frequently, and the
timestamp in the State Cookie MAY be used to determine which key
should be used to verify the MAC.
An implementation SHOULD make the cookie as small as possible to
insure interoperability.
5.1.4 State Cookie Processing
When an endpoint (in the COOKIE WAIT state) receives an INIT ACK
chunk with a State Cookie parameter, it MUST immediately send a
COOKIE ECHO chunk to its peer with the received State Cookie. The
sender MAY also add any pending DATA chunks to the packet after the
COOKIE ECHO chunk.
The endpoint shall also start the T1-cookie timer after sending out
the COOKIE ECHO chunk. If the timer expires, the endpoint shall
retransmit the COOKIE ECHO chunk and restart the T1-cookie timer.
This is repeated until either a COOKIE ACK is received or '
Max.Init.Retransmits' is reached causing the peer endpoint to be
marked unreachable (and thus the association enters the CLOSED
state).
5.1.5 State Cookie Authentication
When an endpoint receives a COOKIE ECHO chunk from another endpoint
with which it has no association, it shall take the following
actions:
1) Compute a MAC using the TCB data carried in the State Cookie and
the secret key (note the timestamp in the State Cookie MAY be used
to determine which secret key to use). Reference [RFC2104] can be
used as a guideline for generating the MAC,
2) Authenticate the State Cookie as one that it previously generated
by comparing the computed MAC against the one carried in the State
Cookie. If this comparison fails, the SCTP packet, including the
COOKIE ECHO and any DATA chunks, should be silently discarded,
3) Compare the creation timestamp in the State Cookie to the current
local time. If the elapsed time is longer than the lifespan
carried in the State Cookie, then the packet, including the COOKIE
ECHO and any attached DATA chunks, SHOULD be discarded and the
endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error
cause to the peer endpoint,
4) If the State Cookie is valid, create an association to the sender
of the COOKIE ECHO chunk with the information in the TCB data
carried in the COOKIE ECHO, and enter the ESTABLISHED state,
5) Send a COOKIE ACK chunk to the peer acknowledging reception of the
COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA
chunk or SACK chunk; however, the COOKIE ACK MUST be the first
chunk in the SCTP packet.
6) Immediately acknowledge any DATA chunk bundled with the COOKIE
ECHO with a SACK (subsequent DATA chunk acknowledgement should
follow the rules defined in Section 6.2). As mentioned in step
5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
MUST appear first in the SCTP packet.
If a COOKIE ECHO is received from an endpoint with which the receiver
of the COOKIE ECHO has an existing association, the procedures in
Section 5.2 should be followed.
5.1.6 An Example of Normal Association Establishment
In the following example, "A" initiates the association and then
sends a user message to "Z", then "Z" sends two user messages to "A"
later (assuming no bundling or fragmentation occurs):
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/--- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=1 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2]
<------/\
\
\------>
Figure 4: INITiation Example
If the T1-init timer expires at "A" after the INIT or COOKIE ECHO
chunks are sent, the same INIT or COOKIE ECHO chunk with the same
Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and
the timer restarted. This shall be repeated Max.Init.Retransmits
times before "A" considers "Z" unreachable and reports the failure to
its upper layer (and thus the association enters the CLOSED state).
When retransmitting the INIT, the endpoint MUST follow the rules
defined in 6.3 to determine the proper timer value.
5.2 Handle Duplicate or Unexpected INIT, INIT ACK, COOKIE ECHO, and
COOKIE ACK
During the lifetime 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 a SCTP transport address and is from a 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, re-started 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 or COOKIE-ECHOED state, an
endpoint MUST respond with an INIT ACK using the same parameters it
sent in its original INIT chunk (including its Initiation Tag,
unchanged). These original parameters are combined with those from
the newly received INIT chunk. The endpoint shall also generate a
State Cookie with the INIT ACK. The endpoint uses the parameters
sent in its INIT to calculate the State Cookie.
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 with the Tag information of itself and its peer (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 reception of an unexpected INIT for
this association, the endpoint shall generate an INIT ACK with a
State Cookie. In the outbound INIT ACK the endpoint MUST copy its
current Verification Tag and peer's Verification Tag into a reserved
place within the state cookie. We shall refer to these locations as
the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet
containing this INIT ACK MUST carry a Verification Tag value equal to
the Initiation Tag found in the unexpected INIT. And the INIT ACK
MUST contain a new Initiation Tag (randomly generated see Section
5.3.1). Other parameters for the endpoint SHOULD be copied from the
existing parameters of the association (e.g. number of outbound
streams) into the INIT ACK and cookie.
After sending out the INIT ACK, the endpoint shall take no further
actions, i.e., the existing association, including its current state,
and the corresponding TCB MUST NOT be changed.
Note: Only when a TCB exists and the association is not in a COOKIE-
WAIT state are the Tie-Tags populated. For a normal association INIT
(i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be
set to 0 (indicating that no previous TCB existed). The INIT ACK and
State Cookie are populated as specified in section 5.2.1.
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 of 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
the peer has restarted (Action A), it MUST NOT setup 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
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 always
enter the ESTABLISHED state, if it has not already done so. It
should stop any init or cookie timers 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 a 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=1 & 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) That 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 setup, 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 re-attempt the setup procedure.
2) Discard the TCB and report to the upper layer the inability to
setup the association.
3) Send a new INIT chunk to the endpoint, adding a Cookie
Preservative parameter requesting an extension to the lifetime 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
lifetimes 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 [RFC1750] 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 lifetime of an
association. A new Verification Tag value MUST be used each time the
endpoint tears-down and then re-establishes an association to the
same peer.
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 COOKIE-WAIT state.
DATA chunks MUST only be received according to the rules below in
ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT. A DATA chunk received
in CLOSED is out of the blue and SHOULD be handled per 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 8.4. A SACK chunk received in
any other state SHOULD be discarded.
A SCTP receiver MUST be able to receive a minimum of 1500 bytes in
one SCTP packet. This means that a 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 Sections
6.9 and 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 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 which are marked for retransmission (limited by the current
cwnd).
D) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B above 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 a 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.
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.
A 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 500ms but MUST NOT raise it above 500ms.
Acknowledgements MUST be sent in SACK chunks unless shutdown was
requested by the ULP in which case an endpoint MAY send an
acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge
the reception of multiple DATA chunks. See Section 3.3.4 for SACK
chunk format. In particular, the SCTP endpoint MUST fill in the
Cumulative TSN Ack field to indicate the latest sequential TSN (of a
valid DATA chunk) it has received. Any received DATA chunks with TSN
greater than the value in the Cumulative TSN Ack field SHOULD also be
reported in the Gap Ack Block fields.
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 circumstance 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 Acknowledgment 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 (via either
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 mark the corresponding DATA chunk as
available for retransmit: Mark it as missing for fast
retransmit as described in Section 7.2.4 and if no retransmit
timer is running for the destination address to which the DATA
chunk was originally transmitted, then T3-rtx is started for
that destination address.
6.3 Management of Retransmission Timer
An SCTP endpoint uses a retransmission timer T3-rtx to ensure data
delivery in the absence of any feedback from its peer. The duration
of this timer is referred to as RTO (retransmission timeout).
When an endpoint's peer is multi-homed, the endpoint will calculate a
separate RTO for each different destination transport address of its
peer endpoint.
The computation and management of RTO in SCTP follows closely how TCP
manages its retransmission timer. To compute the current RTO, an
endpoint maintains two state variables per destination transport
address: SRTT (smoothed round-trip time) and RTTVAR (round-trip time
variation).
6.3.1 RTO Calculation
The rules governing the computation of SRTT, RTTVAR, and RTO are as
follows:
C1) Until an RTT measurement has been made for a packet sent to the
given destination transport address, set RTO to the protocol
parameter 'RTO.Initial'.
C2) When the first RTT measurement R is made, set SRTT <- R, RTTVAR
<- R/2, and RTO <- SRTT + 4 * RTTVAR.
C3) When a new RTT measurement R' is made, set
RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| SRTT
<- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R'
Note: The value of SRTT used in the update to RTTVAR is its value
before updating SRTT itself using the second assignment.
After the computation, update RTO <- SRTT + 4 * RTTVAR.
C4) When data is in flight and when allowed by rule C5 below, a new
RTT measurement MUST be made each round trip. Furthermore, new
RTT measurements SHOULD be made no more than once per round-trip
for a given destination transport address. There are two reasons
for this recommendation: First, it appears that measuring more
frequently often does not in practice yield any significant
benefit [ALLMAN99]; second, if measurements are made more often,
then the values of RTO.Alpha and RTO.Beta in rule C3 above should
be adjusted so that SRTT and RTTVAR still adjust to changes at
roughly the same rate (in terms of how many round trips it takes
them to reflect new values) as they would if making only one
measurement per round-trip and using RTO.Alpha and RTO.Beta as
given in rule C3. However, the exact nature of these adjustments
remains a research issue.
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).
C6) Whenever RTO is computed, if it is less than RTO.Min seconds then
it is rounded up to RTO.Min seconds. The reason for this rule is
that RTOs that do not have a high minimum value are susceptible
to unnecessary timeouts [ALLMAN99].
C7) A maximum value may be placed on RTO provided it is at least
RTO.max seconds.
There is no requirement for the clock granularity G used for
computing RTT measurements and the different state variables, other
than:
G1) Whenever RTTVAR is computed, if RTTVAR = 0, then adjust RTTVAR <-
G.
Experience [ALLMAN99] has shown that finer clock granularities (<=
100 msec) perform somewhat better than more coarse granularities.
6.3.2 Retransmission Timer Rules
The rules for managing the retransmission timer are as follows:
R1) Every time a DATA chunk is sent to any address (including a
retransmission), if the T3-rtx timer of that address is not
running, start it running so that it will expire after the RTO of
that address. The RTO used here is that obtained after any
doubling due to previous T3-rtx timer expirations on the
corresponding destination address as discussed in rule E2 below.
R2) Whenever all outstanding data sent to an address have been
acknowledged, turn off the T3-rtx timer of that address.
R3) Whenever a SACK is received that acknowledges the DATA chunk with
the earliest outstanding TSN for that address, restart T3-rtx
timer for that address with its current RTO (if there is still
outstanding data on that address).
R4) Whenever a SACK is received missing a TSN that was previously
acknowledged via a Gap Ack Block, start T3-rtx for the
destination address to which the DATA chunk was originally
transmitted if it is not already running.
The following example shows the use of various timer rules (assuming
the receiver uses delayed acks).
Endpoint A Endpoint Z
{App begins to send}
Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed)
(Start T3-rtx timer)
{App sends 1 message; strm 1}
(bundle ack with data)
DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN Ack=7,Block=0]
\ / DATA [TSN=6,Strm=1,Seq=2]
\ / (Start T3-rtx timer)
\
/ \
(Re-start T3-rtx timer) <------/ \--> (ack delayed)
(ack delayed)
{send ack}
SACK [TSN Ack=6,Block=0] --------------> (Cancel T3-rtx timer)
..
(send ack)
(Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0]
Figure 8 - Timer Rule Examples
6.3.3 Handle T3-rtx Expiration
Whenever the retransmission timer T3-rtx expires for a destination
address, do the following:
E1) For the destination address for which the timer expires, adjust
its ssthresh with rules defined in Section 7.2.3 and set the cwnd
<- MTU.
E2) For the destination address for which the timer expires, set RTO
<- RTO * 2 ("back off the timer"). The maximum value discussed
in rule C7 above (RTO.max) may be used to provide an upper bound
to this doubling operation.
E3) Determine how many of the earliest (i.e., lowest TSN) outstanding
DATA chunks for the address for which the T3-rtx has expired will
fit into a single packet, subject to the MTU constraint for the
path corresponding to the destination transport address to which
the retransmission is being sent (this may be different from the
address for which the timer expires [see Section 6.4]). Call
this value K. Bundle and retransmit those K DATA chunks in a
single packet to the destination endpoint.
E4) Start the retransmission timer T3-rtx on the destination address
to which the retransmission is sent, if rule R1 above indicates
to do so. The RTO to be used for starting T3-rtx should be the
one for the destination address to which the retransmission is
sent, which, when the receiver is multi-homed, may be different
from the destination address for which the timer expired (see
Section 6.4 below).
After retransmitting, once a new RTT measurement is obtained (which
can happen only when new data has been sent and acknowledged, per
rule C5, or for a measurement made from a HEARTBEAT [see Section
8.3]), the computation in rule C3 is performed, including the
computation of RTO, which may result in "collapsing" RTO back down
after it has been subject to doubling (rule E2).
Note: Any DATA chunks that were sent to the address for which the
T3-rtx timer expired but did not fit in one MTU (rule E3 above),
should be marked for retransmission and sent as soon as cwnd allows
(normally when a SACK arrives).
The final rule for managing the retransmission timer concerns
failover (see Section 6.4.1):
F1) Whenever an endpoint switches from the current destination
transport address to a different one, the current retransmission
timers are left running. As soon as the endpoint transmits a
packet containing DATA chunk(s) to the new transport address,
start the timer on that transport address, using the RTO value of
the destination address to which the data is being sent, if rule
R1 indicates to do so.
6.4 Multi-homed SCTP Endpoints
An SCTP endpoint is considered multi-homed if there are more than one
transport address that can be used as a destination address to reach
that endpoint.
Moreover, the ULP of an endpoint shall select one of the multiple