| TOC |
|
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 30, 2002.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document contains a compilation of all defects found up until the publishing of this document for the Stream Control Transmission Protocol (SCTP) RFC2960[3]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of SCTP to clarify errors in the original SCTP document.
This document updates RFC2960[3] and text within this document supersedes the text found in RFC2960[3].
| TOC |
| TOC |
This document contains a compilation of all defects found up until the publishing of this document for the Stream Control Transmission Protocol (SCTP) RFC2960[3]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of SCTP to clarify errors in the original SCTP document.
This document updates RFC2960 and text within this document, where noted, supersedes the text found in RFC2960[3]. Each error will be detailed within this document in the form of:
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119[2].
| TOC |
A typo was discovered in RFC2960[3] that incorrectly specifies an action to be taken when processing chunks of unknown identity.
---------
Old text: (Section 3.2)
---------
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
---------
New text: (Section 3.2)
---------
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
chunk in an 'Unrecognized Chunk Type'.
The receiver of an unrecognized Chunk should not send a 'parameter' error but instead the appropriate chunk error as described above.
A typographical error was introduced through an improper cut and paste in the use of the upper two bits to describe proper handling of unknown parameters.
---------
Old text: (Section 3.2.1)
---------
00 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it.
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this SCTP chunk and discard it, do not process
any further parameters within this chunk.
01 - Stop processing this SCTP chunk and discard it, do not process
any further parameters within this chunk, and report the
unrecognized parameter in an 'Unrecognized Parameter Type' (in
either an ERROR or in the INIT ACK).
It was always the intent to stop processing at the level one was at in an unknown chunk or parameter with the upper bit set to 0. Thus if you are processing a chunk, you should drop the packet. If you are processing a parameter, you should drop the chunk.
A problem was found in that when a Chunk terminated in a TLV parameter. If this last TLV was not on a 32 bit boundary (as required), there was confusion as to if the last padding was included in the chunk length.
--------- Old text: (Section 3.2) --------- Chunk Length: 16 bits (unsigned integer) This value represents the size of the chunk in bytes including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any padding. Chunk Value: variable length The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type. The total length of a chunk (including Type, Length and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes and this padding is not included in the chunk length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes. --------- New text: (Section 3.2) --------- Chunk Length: 16 bits (unsigned integer) This value represents the size of the chunk in bytes including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any chunk padding. Chunks (including Type, Length and Value fields) are padded out by the sender with all zero bytes to be a multiple of 4 bytes long. This padding MUST NOT be more than 3 bytes in total. The Chunk Length value does not include terminating padding of the Chunk. However, it does include padding of any variable length parameter except the last parameter in the Chunk. The receiver MUST ignore the padding. Note: A robust implementation should accept the Chunk whether or not the final padding has been included in the Chunk Length. Chunk Value: variable length The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type.
The above text makes clear that the padding of the last parameter is not included in the Chunk Length field. It also clarifies that the padding of parameters that are not the last one must be counted in the Chunk Length field.
A problem was noted when multiple errors are needed to be sent regarding unknown or unrecognized parameters. Since often times the error type does not hold the chunk type field, it may become difficult to tell which error was associated with which chunk.
--------- Old text: (Section 3.2.1) --------- The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 13.2. --------- New text: (Section 3.2.1) --------- The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 13.2. Note that a parameter type MUST be unique across all chunks. For example, the parameter type '5' is used to represent an IPv4 address (see section 3.3.2). The value '5' then is reserved across all chunks to represent an IPv4 address and MUST NOT be reused with a different meaning in any other chunk. --------- Old text: (Section 13.2) --------- 13.2 IETF-defined Chunk Parameter Extension The assignment of new chunk parameter type codes is done through an IETF Consensus action as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information: a) Name of the parameter type. b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2.1. c) Detailed definition of each component of the parameter type. d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk. --------- New text: (Section 13.2) --------- 13.2 IETF-defined Chunk Parameter Extension The assignment of new chunk parameter type codes is done through an IETF Consensus action as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information: a) Name of the parameter type. b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2.1. c) Detailed definition of each component of the parameter type. d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk. e) Each parameter type MUST be unique across all chunks.
By having all parameters unique across all chunk assignments (the current assignment policy) no ambiguity exists as to what a parameter means based on context. The trade off for this is a smaller parameter space i.e. 65,536 parameters versus 65,536 * Number-of-chunks.
A problem was found where the specification is unclear on the legality of an endpoint asking for more stream resources than were allowed in the MIS value of the INIT. In particular the value in the INIT ACK requested in its OS value was larger than the MIS value received in the INIT chunk. This behavior is illegal yet it was unspecified in RFC2960[3]
--------- Old text: (Section 3.3.3) --------- Number of Outbound Streams (OS): 16 bits (unsigned integer) Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used. Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB. --------- New text: (Section 3.3.3) --------- Number of Outbound Streams (OS): 16 bits (unsigned integer) Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used and the value MUST NOT be greater than the MIS value sent in the INIT chunk. Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB.
The change in wording, above, changes it so that a responder to an INIT chunk does not specify more streams in its OS value than was represented to it in the MIS value i.e. its maximum.
A security problem was found when a restart occurs. It is possible for an intruder to send an INIT to an endpoint of an existing association. In the INIT the intruder would list one or more of the current addresses of an association and its own. The normal restart procedures would then occur and the intruder would have hi-jacked an association.
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an association with new addresses
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text: (Note no old text, new error added in section 3.3.10)
---------
3.3.10.11 Restart of an association with new addresses (11)
Cause of error
--------------
Restart of an association with new addresses: An INIT was received
on an existing association. But the INIT added addresses to the
association that were previously NOT part of the association. The
New addresses are listed in the error code. This ERROR is normally
sent as part of an ABORT refusing the INIT (see section 5.2).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\\ \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---------
Old text: (Section 5.2.1)
---------
Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an
endpoint MUST respond with an INIT ACK using the same parameters it
sent in its original INIT chunk (including its Initiation Tag,
unchanged). These original parameters are combined with those from
the newly received INIT chunk. The endpoint shall also generate a
State Cookie with the INIT ACK. The endpoint uses the parameters
sent in its INIT to calculate the State Cookie.
---------
New text: (Section 5.2.1)
---------
Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
respond with an INIT ACK using the same parameters it sent in its
original INIT chunk (including its Initiation Tag, unchanged). When
responding the endpoint MUST send the INIT ACK back to the same
address that the original INIT (sent by this endpoint) was sent to.
Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
respond with an INIT ACK using the same parameters it sent in its
original INIT chunk (including its Initiation Tag, unchanged)
provided that no NEW address have been added to the forming
association. If the INIT message indicates that a new address(es)
have been added to the association, then the entire INIT MUST be
discarded and NO changes should be made to the existing association.
An ABORT MUST be sent in response that SHOULD 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.
---------
Old text: (Section 5.2.2)
---------
5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
COOKIE-WAIT and SHUTDOWN-ACK-SENT
Unless otherwise stated, upon reception of an unexpected INIT for
this association, the endpoint shall generate an INIT ACK with a
State Cookie. In the outbound INIT ACK the endpoint MUST copy its
current Verification Tag and peer's Verification Tag into a reserved
place within the state cookie. We shall refer to these locations as
the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet
containing this INIT ACK MUST carry a Verification Tag value equal to
the Initiation Tag found in the unexpected INIT. And the INIT ACK
MUST contain a new Initiation Tag (randomly generated see Section
5.3.1). Other parameters for the endpoint SHOULD be copied from the
existing parameters of the association (e.g. number of outbound
streams) into the INIT ACK and cookie.
After sending out the INIT ACK, the endpoint shall take no further
actions, i.e., the existing association, including its current state,
and the corresponding TCB MUST NOT be changed.
Note: Only when a TCB exists and the association is not in a COOKIE-
WAIT state are the Tie-Tags populated. For a normal association INIT
(i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be
set to 0 (indicating that no previous TCB existed). The INIT ACK and
State Cookie are populated as specified in section 5.2.1.
---------
New text: (Section 5.2.2)
---------
5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
COOKIE-WAIT and SHUTDOWN-ACK-SENT
Unless otherwise stated, upon reception 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 'Initiation Tag' of the unexpected INIT
into the 'Verification Tag' of the outbound packet carrying the ABORT.
In the ABORT response the cause of error SHOULD be set to 'restart
of an association with new addresses'. The error SHOULD list the
addresses that were added to the restarting association.
If no new addresses are added, when responding to the INIT in the
outbound INIT ACK the endpoint MUST copy its current Verification Tag
and peer's Verification Tag into a reserved place within the state
cookie. We shall refer to these locations as the Peer's-Tie-Tag and
the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK
MUST carry a Verification Tag value equal to the Initiation Tag found
in the unexpected INIT. And the INIT ACK MUST contain a new
Initiation Tag (randomly generated see Section 5.3.1). Other
parameters for the endpoint SHOULD be copied from the existing
parameters of the association (e.g. number of outbound streams) into
the INIT ACK and cookie.
After sending out the INIT ACK or ABORT, the endpoint shall take no
further actions, i.e., the existing association, including its
current state, and the corresponding TCB MUST NOT be changed.
Note: Only when a TCB exists and the association is not in a COOKIE-
WAIT, COOKIE-ECHOED 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).
A new error code is being added and specific instructions to send back an ABORT to a new association in a restart case or collision case, where new addresses have been added. The error code can be used by a legitimate restart to inform the endpoint that it has made a software error in adding a new address. The endpoint then can choose to wait until the OOTB ABORT tears down the old association, or restart without the new address.
Also the Note at the end of section 5.2.2 explaining the use of the Tie-Tags was modified to properly explain the states in which the Tie-Tags should be set to a value different than 0.
Some implementations were having difficulty growing their cwnd. This was due to an improper enforcement of the congestion control rules. The rules, as written, provided for a slop over of the cwnd value. Without this slop over the sender would appear to NOT be using its full cwnd value and thus never increase it.
--------- Old text: (Section 6.1) --------- B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address. --------- New text: (Section 6.1) --------- B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address. The sender may exceed cwnd by up to (PMTU-1) bytes on a new transmission if the cwnd is not currently exceeded.
The text changes make clear the ability to go over the cwnd value by no more than (PMTU-1) bytes.
A problem was found in the current specification of fast retransmit. In particular in a high bandwidth * delay network. The current wording did not require GAP ACK blocks to be sent, even though they are essential to the workings of SCTP's congestion control. Also the specification left unclear how to handle the fast retransmit cycle, having the implementation to wait on the cwnd to retransmit a TSN that was marked for fast retransmit. Also no limit was placed on how many times a TSN could be fast retransmitted.
---------
Old text: (Section 6.2)
---------
Acknowledgments MUST be sent in SACK chunks unless shutdown was
requested by the ULP in which case an endpoint MAY send an
acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge
the reception of multiple DATA chunks. See Section 3.3.4 for SACK
chunk format. In particular, the SCTP endpoint MUST fill in the
Cumulative TSN Ack field to indicate the latest sequential TSN (of a
valid DATA chunk) it has received. Any received DATA chunks with TSN
greater than the value in the Cumulative TSN Ack field SHOULD also be
reported in the Gap Ack Block fields.
---------
New text: (Section 6.2)
---------
Acknowledgments MUST be sent in SACK chunks unless shutdown was
requested by the ULP in which case an endpoint MAY send an
acknowledgment 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 MUST also be
reported in the Gap Ack Block fields.
---------
Old text: (Section 7.2.4)
---------
When the TSN(s) is reported as missing in the fourth consecutive
SACK, the data sender shall:
1) Mark the missing DATA chunk(s) for retransmission,
2) Adjust the ssthresh and cwnd of the destination address(es) to
which the missing DATA chunks were last sent, according to the
formula described in Section 7.2.3.
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address
to which the packet is being sent. Call this value K. Retransmit
those K DATA chunks in a single packet.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first.
A straightforward implementation of the above keeps a counter for
each TSN hole reported by a SACK. The counter increments for each
consecutive SACK reporting the TSN hole. After reaching 4 and
starting the fast retransmit procedure, the counter resets to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size.
---------
New text: (Section 7.2.4)
---------
When the TSN(s) is reported as missing in the fourth consecutive
SACK, the data sender shall:
1) Mark the missing DATA chunk(s) for retransmission as described
below in M1-M3,
2) Adjust the ssthresh and cwnd of the destination address(es) to
which the missing DATA chunks were last sent, according to the
formula described in Section 7.2.3.
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address
to which the packet is being sent. Call this value K. Retransmit
those K DATA chunks in a single packet. When a Fast Retransmit is
being performed the sender SHOULD ignore the value of cwnd and
SHOULD NOT delay retransmission.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
5) Mark the DATA chunk(s) as being fast retransmitted and thus
ineligible for a subsequent fast retransmit. Those TSNs marked
for retransmission due to the Fast Retransmit algorithm that
did not fit in the sent datagram carrying K other TSNs are also
marked as ineligible for a subsequent fast retransmit. However,
as they are marked for retransmission they will be retransmitted
later on as soon as cwnd allows.
Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first.
A straightforward implementation of the above is as follows:
M1) Each time a new DATA chunk is transmitted set the
'TSN.Missing.Report' count for that TSN to 0. The
'TSN.Missing.Report' count will be used to determine missing
chunks and when to fast retransmit.
M2) Each time a SACK arrives reporting 'Stray DATA chunk(s)' record
the highest TSN reported as newly acknowledged, call this
value 'HighestTSNinSack'. A newly acknowledged DATA chunk is one
not previously acknowledged in a SACK.
When the SCTP sender of data receives a SACK chunk that
acknowledges, for the first time, the receipt of a DATA chunk,
all the still unacknowledged DATA chunks whose TSN is older than
that newly acknowledged DATA chunk, are qualified as
'Stray DATA chunks'.
M3) Examine all 'Unacknowledged TSN's', if the TSN number of an
'Unacknowledged TSN' is smaller than the 'HighestTSNinSack'
value, increment the 'TSN.Missing.Report' count on that chunk if
it has NOT been fast retransmitted or marked for fast retransmit
already.
M4) If any DATA chunk is found to have a 'TSN.Missing.Report' value
larger than or equal to 4, mark that chunk for retransmission and
start the fast retransmit procedure (steps 2-5 above).
M5) If a T3-rtx timer expires, the 'TSN.Missing.Report' of all
affected TSNs is set to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size.
The effect of the above wording changes are as follows:
These changes will effectively allow SCTP to follow a similar model as TCP+SACK in the handling of Fast Retransmit.
SCTP uses four control variables to regulate its transmission rate: rwnd, cwnd, ssthresh and partial_bytes_acked. Upon detection of packet losses from SACK or when the T3-rtx timer expires on an address cwnd and ssthresh should be updated as stated in section 7.2.3. However, that section should also clarify that partial_bytes_acked must be updated as well, having to be reset to 0.
--------- Old text: (Section 7.2.3) --------- 7.2.3 Congestion Control Upon detection of packet losses from SACK (see Section 7.2.4), An endpoint should do the following: ssthresh = max(cwnd/2, 2*MTU) cwnd = ssthresh Basically, a packet loss causes cwnd to be cut in half. When the T3-rtx timer expires on an address, SCTP should perform slow start by: ssthresh = max(cwnd/2, 2*MTU) cwnd = 1*MTU --------- New text: (Section 7.2.3) --------- 7.2.3 Congestion Control Upon detection of packet losses from SACK (see Section 7.2.4), an endpoint should do the following: ssthresh = max(cwnd/2, 2*MTU) cwnd = ssthresh partial_bytes_acked = 0 Basically, a packet loss causes cwnd to be cut in half. When the T3-rtx timer expires on an address, SCTP should perform slow start by: ssthresh = max(cwnd/2, 2*MTU) cwnd = 1*MTU partial_bytes_acked = 0
The missing text added solves the doubts about what to do with partial_bytes_acked in the situations stated in section 7.2.3, making clear that along with ssthresh and cwnd, partial_bytes_acked should also be updated, having to be reset to 0.
Five basic problems have been discovered with the current heartbeat procedures:
--------- Old text: (Section 8.1) --------- 8.1 Endpoint Failure Detection An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (including retransmissions to all the destination transport addresses of the peer if it is multi-homed). If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall consider the peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint shall report the failure to the upper layer, and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable. The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK), or a HEARTBEAT-ACK is received from the peer endpoint. --------- New text: (Section 8.1) --------- 8.1 Endpoint Failure Detection An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT Chunks. If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall consider the peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint shall report the failure to the upper layer, and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable. The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK), or a HEARTBEAT-ACK is received from the peer endpoint. --------- Old text: (Section 8.3) --------- 8.3 Path Heartbeat By default, an SCTP endpoint shall monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). --------- New text: (Section 8.3) --------- 8.3 Path Heartbeat By default, an SCTP endpoint shall monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). HEARTBEAT sending MAY begin upon reaching the ESTABLISHED state, and is discontinued after sending either SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state (INIT sender) or the ESTABLISHED state (INIT receiver), up until reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-ACK-SENT state (SHUTDOWN receiver). --------- Old text: (Section 8.3) --------- The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information field copied from the received HEARTBEAT chunk. --------- New text: (Section 8.3) --------- The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information TLV, together with any other received TLVs, copied unchanged from the received HEARTBEAT chunk. --------- Old text: (Section 8.3) --------- On an idle destination address that is allowed to heartbeat, a HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that destination address plus the protocol parameter 'HB.interval' , with jittering of +/- 50%, and exponential back-off of the RTO if the previous HEARTBEAT is unanswered. --------- New text: (Section 8.3) --------- On an idle destination address that is allowed to heartbeat, a HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that destination address plus the protocol parameter 'HB.interval' , with jittering of +/- 50% of the RTO value, and exponential back-off of the RTO if the previous HEARTBEAT is unanswered.
The above text provides guidance as to how to respond to the five issues mentioned in Description of the problem In particular the wording changes provide guidance as to when to start and stop heartbeating, how to respond to a heartbeat with extra parameters, and clarifies the error counting procedures for the association.
When dealing with firewalls it is advantageous to the firewall to be able to properly determine the initial startup sequence of a reliable transport protocol. With this in mind the following text is to be added to SCTP's security section.
---------
New text: (no old text, new section added)
---------
11.4 SCTP interactions with firewalls
It is helpful for some firewalls if they can inspect
just the first fragment of a fragmented SCTP packet and unambiguously
determine whether it corresponds to an INIT chunk (for further information
please refer to RFC1858). Accordingly, we
stress the requirements stated in 3.1 that (1) an INIT chunk MUST NOT
be bundled with any other chunk in a packet, and (2) a packet
containing an INIT chunk MUST have a zero Verification Tag.
Furthermore, we require that the receiver of an INIT chunk MUST
enforce these rules by silently discarding an arriving packet with an
INIT chunk that is bundled with other chunks.
---------
Old text: (Section 18)
---------
18. Bibliography
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999.
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
---------
New text: (Section 18)
---------
18. References
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999.
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
The above text adding a new subsection to the Security Considerations section of RFC2960[3] makes clear that, to make easier the interaction with firewalls, an INIT chunk must not be bundled in any case with any other chunk, being this rule enforced by the packet receiver, that will silently discard the packets that do not follow this rule.
Currently there is an ambiguity between the statements in section 6.2 and section 9.2. Section 6.2 allows the sending of a SHUTDOWN chunk in place of a SACK when the sender is in the process of shutting down, while section 9.2 requires both a SHUTDOWN chunk and a SACK chunk to be sent.
Along with this ambiguity there is a problem where in an errant SHUTDOWN receiver may fail to stop accepting user data.
--------- Old text: (Section 9.2) --------- If there are still outstanding DATA chunks left, the SHUTDOWN receiver shall continue to follow normal data transmission procedures defined in Section 6 until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user. While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunk(s) with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If it has no more outstanding DATA chunks, the SHUTDOWN receiver shall send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must re-send the SHUTDOWN ACK. --------- New text: (Section 9.2) --------- If there are still outstanding DATA chunks left, the SHUTDOWN receiver shall continue to follow normal data transmission procedures defined in Section 6 until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user. While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunk(s) with a SHUTDOWN chunk, and restart the T2-shutdown timer. If a SHUTDOWN chunk by itself cannot acknowledge all of the received DATA chunks (i.e. there are TSN's that can be acknowledged that are larger than the cumulative TSN and thus gaps exist in the TSN sequence) then a SACK chunk MUST also be sent. The sender of the SHUTDOWN MAY also start an overall guard timer 'T5-shutdown-guard' to bound the overall time for shutdown sequence. At the expiration of this timer the sender SHOULD abort the association by sending an ABORT chunk. If the 'T5-shutdown-guard' timer is used, it SHOULD be set to the recommended value of 5 times 'RTO.Max'. If the receiver of the SHUTDOWN has no more outstanding DATA chunks, the SHUTDOWN receiver shall send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
The above text clarifies the use of a SACK in conjunction with a SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown sequence to protect against errant receivers of SHUTDOWN chunks.
It was noted that the wording in section 8.5.1 did not give proper directions in the use of the 'T bit' with the verification tags.
---------
Old text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
- The endpoint shall always fill in the Verification Tag field of
the outbound packet with the destination endpoint's tag value
if it is known.
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4.
- The receiver MUST accept the packet if the Verification Tag
matches either its own tag, OR the tag of its peer. Otherwise,
the receiver MUST silently discard the packet and take no
further action.
---------
New text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
- The endpoint shall always fill in the Verification Tag field of
the outbound packet with the destination endpoint's tag value
if it is known.
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4.
- The receiver of a ABORT shall accept the packet if the
Verification Tag field of the packet matches its own tag OR it
is set to its peer's tag and the T bit is set in the Chunk
Flags. Otherwise, the receiver MUST silently discard the packet
and take no further action.
The above text change clarifies that the T bit must be set before an implementation looks for the peers tag.
A problem was found with the current specification of the growth and decay of cwnd. The cwnd should only be increased if it is being fully utilized, and after periods of under utilization, the cwnd should be decreased. In some sections, the current wording is weak and is not clearly defined. Also, the current specification unnecessarily introduces the need for special case code to ensure cwnd degradation.
---------
Old text: (Section 6.1)
---------
D) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B above allow.
---------
New text: (Section 6.1)
---------
D) When the time comes for the sender to transmit new DATA chunks, the
protocol parameter Max.Burst MUST first be applied to limit how many
new DATA chunks may be sent. The limit is applied by adjusting cwnd
as follows:
if((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize + Max.Burst*MTU
E) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B above allow.
---------
Old text: (Section 7.2.1)
---------
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
use the slow start algorithm to increase cwnd (assuming the
current congestion window is being fully utilized). If an
incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be
increased by at most the lesser of 1) the total size of the
previously outstanding DATA chunk(s) acknowledged, and 2) the
destination's path MTU. This protects against the ACK-Splitting
attack outlined in [SAVAGE99].
---------
New text: (Section 7.2.1)
---------
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
use the slow start algorithm to increase cwnd only if the
current congestion window is being fully utilized and an
incoming SACK advances the Cumulative TSN Ack Point. Only when
these two conditions are met can the cwnd be increased otherwise
the cwnd MUST not be increased. If these conditions are met then
cwnd MUST be increased by at most the lesser of 1) the total
size of the previously outstanding DATA chunk(s) acknowledged,
and 2) the destination's path MTU. This protects against the
ACK-Splitting attack outlined in [SAVAGE99].
---------
Old text: (Section 7.2.1)
---------
o When the endpoint does not transmit data on a given transport
address, the cwnd of the transport address should be adjusted to
max(cwnd/2, 2*MTU) per RTO.
---------
New text: (Section 7.2.1)
---------
o When the association does not transmit data on a given transport address
within an RTO, the cwnd of the transport address MUST be adjusted to
2*MTU.
---------
Old text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit DATA
on a given transport address, the cwnd of the transport address
should be adjusted to max(cwnd / 2, 2*MTU) per RTO.
---------
New text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit DATA on
a given transport address within an RTO, the cwnd of the transport
address should be adjusted to 2*MTU.
---------
Old text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
---------
New text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.Interval - 30 seconds
The above changes strengthens the rules and makes it much more apparent as to the need to block cwnd growth when the full cwnd is not being utilized. The changes also applies cwnd degradation without introducing the need for complex special case code.
When a receiver clamps its rwnd to 0 to flow control the peer, the specification implies that one must continue to accept data from the remote peer. This is incorrect and needs clarification.
--------- Old text: (Section 6.2) --------- The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk. --------- New text: (Section 6.2) --------- 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 all new incoming DATA chunk and immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk 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 RFC 813. The algorithm can be similar to the one described in Section 4.2.3.3 of RFC 1122. Because of receiver SWS avoidance, even when the receiver's internal buffer is not full anymore, as long as the advertised window is still 0, the receiver MUST still drop all new incoming DATA chunk. --------- Old text: (Section 6.1) --------- 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. --------- New text: (Section 6.1) --------- 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. When the receiver's advertised window is zero, this probe is called a zero window probe. Note that zero window probe SHOULD only be sent when all outstanding DATA chunks have been cumulatively acknowledged and no DATA chunk(s) are in flight. Zero window probing MUST be supported. When a sender is doing zero window probing, it should not time out the association if it continues to receive new packets from the receiver. The reason is that 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 algorithm in sending new DATA chunks to avoid silly window syndrome (SWS) as described in RFC 813. The algorithm can be similar to the one described in Section 4.2.3.4 of RFC 1122.
The above allows a receiver to drop new data that arrives and yet still requires the receiver to send a SACK showing the conditions unchanged (with the possible exception of a new a_rwnd) and the dropped chunk as missing. This will allow the association to continue until the rwnd condition clears.
The current wording of the Fragmentation and Reassembly forces an implementation that supports fragmentation to always fragment. This prohibits an implementation from offering its users an option to disable sends that exceed the SCTP fragmentation point.
The restriction in RFC2960[3] section 6.9 was never meant to restrict an implementations API from this behavior.
--------- Old text: (Section 6.1) --------- 6.9 Fragmentation and Reassembly An endpoint MAY support fragmentation when sending DATA chunks, but MUST support reassembly when receiving DATA chunks. If an endpoint supports fragmentation, it MUST fragment a user message if the size of the user message to be sent causes the outbound SCTP packet size to exceed the current MTU. If an implementation does not support fragmentation of outbound user messages, the endpoint must return an error to its upper layer and not attempt to send the user message. IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer. --------- New text: (Section 6.1) --------- 6.9 Fragmentation and Reassembly An endpoint MAY support fragmentation when sending DATA chunks, but MUST support reassembly when receiving DATA chunks. If an endpoint supports fragmentation, it MUST fragment a user message if the size of the user message to be sent causes the outbound SCTP packet size to exceed the current MTU. If an implementation does not support fragmentation of outbound user messages, the endpoint must return an error to its upper layer and not attempt to send the user message. Note: If an implementation that supports fragmentation makes available to its upper layer a mechanism to turn off fragmentation it may do so. However in so doing, it MUST react just like an implementation that does NOT support fragmentation i.e. it MUST reject sends that exceed the current P-MTU. IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer.
The above wording will allow an implementation to offer the option of rejecting sends that exceed the P-MTU size even when the implementation supports fragmentation.
The current description of the SACK chunk within the RFC does not clearly state the value that would be put within a SACK when no DATA chunk has been received.
--------- Old text: (Section 3.3.4) --------- Cumulative TSN Ack: 32 bits (unsigned integer) This parameter contains the TSN of the last DATA chunk received in sequence before a gap. --------- New text: (Section 3.3.4) --------- Cumulative TSN Ack: 32 bits (unsigned integer) This parameter contains the TSN of the last DATA chunk received in sequence before a gap. In the case where no DATA chunk has been received, this value is set to the peers Initial TSN minus one.
This change clearly states what the initial value will be for a SACK sender.
The current description on handling address parameters contained within the INIT and INIT-ACK do not fully describe a requirement for their handling.
--------- Old text: (Section 5.1.2) --------- 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. --------- New text: (Section 5.1.2) --------- 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. D) When searching for a matching TCB upon reception of an INIT or INIT-ACK chunk the receiver SHOULD use not only the source address of the packet (containing the INIT or INIT-ACK) but the receiver SHOULD also use all valid address parameters contained within the chunk.
This new text clearly specifies to an implementor the need to look within the INIT or INIT-ACK. Any implementation that does not do this, may not be able to establish associations in certain circumstances.
The current wording in the RFC places the choice of sending an ABORT upon the SCTP stack when a stream shortage occurs. This decision should really be made by the upper layer not the SCTP stack.
--------- Old text: --------- 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. --------- New text: (Section 5.1.2) --------- 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 use MIS outbound streams and MAY report any shortage to the upper layer. The upper layer can then choose to abort the association if the resource shortage is unacceptable.
The above changes take the decision to ABORT out of the realm of the SCTP stack and places it into the users hands.
The current RFC does not provide any guidance on the assignment of TSN sequence numbers to outbound message nor reception of these message. This could lead to a possible indefinite postponement.
---------
Old text: (Section 6.1)
---------
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 Acknowledgment on Reception of DATA Chunks
---------
New text: (Section 6.1)
---------
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.
The algorithm by which an implementation assigns sequential TSNs to
messages on a particular association MUST ensure that no user
message that has been accepted by SCTP is indefinitely postponed
from being assigned a TSN. Acceptable algorithms for assigning TSNs
include
(a) assigning TSNs in round-robin order over all streams with
pending data
(b) preserving the linear order in which the user messages were
submitted to the SCTP association.
When an upper layer requests to read data on an SCTP association,
the SCTP receiver SHOULD choose the message with the lowest TSN from
among all deliverable messages. In SCTP implementations that allow a
user to request data on a specific stream, this operation SHOULD NOT
block if data is not available, since this can lead to a deadlock
under certain conditions.
6.2 Acknowledgment on Reception of DATA Chunks
The above wording clarifies how TSNs SHOULD be assigned by the sender.
It is not possible for an upper layer to abort the association and provide the peer with an indication why the association is aborted.
Some of the changes given here already include changes suggested in section 2.6.2 of this document.
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an association with new addresses
12 User Initiated Abort
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause-specific Information: variable length
This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are
discussed in Section 13.3.
---------
New text: (Note no old text, new error added in section 3.3.10)
---------
3.3.10.12 User Initiated Abort (12)
Cause of error
--------------
This error cause MAY be included in ABORT chunks which are send
because of an upper layer request. The upper layer can specify
an Upper Layer Abort Reason which is transported by SCTP
transparently and MAY be delivered to the upper layer protocol
at the peer.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=12 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Upper Layer Abort Reason /
\\ \\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---------
Old text: (Section 9.1)
---------
9.1 Abort of an Association
When an endpoint decides to abort an existing association, it shall
send an ABORT chunk to its peer endpoint. The sender MUST fill in
the peer's Verification Tag in the outbound packet and MUST NOT
bundle any DATA chunk with the ABORT.
An endpoint MUST NOT respond to any received packet that contains an
ABORT chunk (also see Section 8.4).
An endpoint receiving an ABORT shall apply the special Verification
Tag check rules described in Section 8.5.1.
After checking the Verification Tag, the receiving endpoint shall
remove the association from its record, and shall report the
termination to its upper layer.
---------
New text: (Section 9.1)
---------
9.1 Abort of an Association
When an endpoint decides to abort an existing association, it shall
send an ABORT chunk to its peer endpoint. The sender MUST fill in
the peer's Verification Tag in the outbound packet and MUST NOT
bundle any DATA chunk with the ABORT. If the association is aborted
on request of the upper layer an User Initiated Abort error cause
(see 3.3.10.12) SHOULD be present in the ABORT chunk.
An endpoint MUST NOT respond to any received packet that contains an
ABORT chunk (also see Section 8.4).
An endpoint receiving an ABORT shall apply the special Verification
Tag check rules described in Section 8.5.1.
After checking the Verification Tag, the receiving endpoint shall
remove the association from its record, and shall report the
termination to its upper layer. If an User Initiated Abort error
cause is present in the ABORT chunk the Upper Layer Abort Reason
shall be made available to the upper layer.
---------
Old text: (Section 10.1)
---------
D) Abort
Format: ABORT(association id [, cause code])
-> result
Ungracefully closes an association. Any locally queued user data
will be discarded and an ABORT chunk is sent to the peer. A success
code will be returned on successful abortion of the association. If
attempting to abort the association results in a failure, an error
code shall be returned.
Mandatory attributes:
o association id - local handle to the SCTP association
Optional attributes:
o cause code - reason of the abort to be passed to the peer.
None.
---------
New text: (Section 10.1)
---------
D) Abort
Format: ABORT(association id [, Upper Layer Abort Reason])
-> result
Ungracefully closes an association. Any locally queued user data
will be discarded and an ABORT chunk is sent to the peer. A success
code will be returned on successful abortion of the association. If
attempting to abort the association results in a failure, an error
code shall be returned.
Mandatory attributes:
o association id - local handle to the SCTP association
Optional attributes:
o Upper Layer Abort Reason - reason of the abort to be passed to the peer.
None.
---------
Old text: (Section 10.2)
---------
E) COMMUNICATION LOST notification
When SCTP loses communication to an endpoint completely (e.g., via
Heartbeats) or detects that the endpoint has performed an abort
operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification:
o association id - local handle to the SCTP association
o status - This indicates what type of event has occurred; The status
may indicate a failure OR a normal termination event
occurred in response to a shutdown or abort request.
The following may be passed with the notification:
o data retrieval id - an identification used to retrieve unsent and
unacknowledged data.
o last-acked - the TSN last acked by that peer endpoint;
o last-sent - the TSN last sent to that peer endpoint;
---------
New text: (Section 10.2)
---------
E) COMMUNICATION LOST notification
When SCTP loses communication to an endpoint completely (e.g., via
Heartbeats) or detects that the endpoint has performed an abort
operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification:
o association id - local handle to the SCTP association
o status - This indicates what type of event has occurred; The status
may indicate a failure OR a normal termination event
occurred in response to a shutdown or abort request.
The following may be passed with the notification:
o data retrieval id - an identification used to retrieve unsent and
unacknowledged data.
o last-acked - the TSN last acked by that peer endpoint;
o last-sent - the TSN last sent to that peer endpoint;
o Upper Layer Abort Reason - the abort reason specified if case of an user
initiated abort.
The above allows an upper layer to provide its peer with an indication why the association was aborted. Therefore an addition error cause was introduced.
RFC 2960 requires that the receiver of an INIT-ACK with the Initiate Tag set to zero handles this as an error and sends back an ABORT. But the sender of the INIT-ACK normally has no TCB and so the ABORT is useless.
---------
Old text: (Section 3.3.3)
---------
Initiate Tag: 32 bits (unsigned integer)
The receiver of the INIT ACK records the value of the Initiate Tag
parameter. This value MUST be placed into the Verification Tag
field of every SCTP packet that the INIT ACK receiver transmits
within this association.
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for
more on the selection of the Initiate Tag value.
If the value of the Initiate Tag in a received INIT ACK chunk is
found to be 0, the receiver MUST treat it as an error and close
the association by transmitting an ABORT.
---------
New text: (Section 3.3.3)
---------
Initiate Tag: 32 bits (unsigned integer)
The receiver of the INIT ACK records the value of the Initiate Tag
parameter. This value MUST be placed into the Verification Tag
field of every SCTP packet that the INIT ACK receiver transmits
within this association.
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for
more on the selection of the Initiate Tag value.
If the value of the Initiate Tag in a received INIT ACK chunk is
found to be 0, the receiver SHOULD destroy the association discarding
its TCB. The receiver MAY send an ABORT for debugging purpose.
The new text does not require the receiver of the invalid INIT-ACK to send the ABORT. This behavior is in tune with the error case of invalid stream numbers in the INIT-ACK. However it is allowed to send an ABORT for helping debugging.
Whenever the receiver of an INIT chunk has to send an ABORT chunk in response for whatever reason it is not stated clearly which Verification Tag and value of the T-bit should be used.
---------
Old text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag set
to '0', process it as described in Section 5.1. Otherwise,
---------
New text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag set
to '0', process it as described in Section 5.1. If, for whatever
reason, the INIT can not be processed normally and an ABORT has to be
sent in response, the Verification Tag of the packet containing the
ABORT chunk MUST be the Initiate tag of the received INIT chunk
and the T-Bit of the ABORT chunk has to be set to 1 indicating that
no TCB was destroyed. Otherwise,
The new text stated clearly which value of the Verification Tag and T-bit have to be used.
| TOC |
The authors would like to thank the following people that have provided comments and input for this document:
A special thanks to Mark Allman, who should actually be a co-author for his work on the max-burst, but managed to wiggle out due to a technicality.
For their comments on the list, Atsushi Fukumoto, David Lehmann.
For their participation in the RTP Bakeoff number 2 and all of their input, Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon Berger, Jon Grim, Dan Harrison, Sabina Torrente, Tomas Orti Martin, Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Robinson, David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Melissa Campbell, Sujith Radhakrishnan, Michael Tuexen, Andreas Jungmaier, Mitch Miers, Fred Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Kacheong Poon, Sverre Slotte, Wang Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep Mahajan, RCMonee, Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep Balani, Biren Patel, Qiaobing Xie, Karl Knutson, La Monte Yarroll, Gareth Keily, Ian Periam, Nathalie Mouellic, and Stan McClellan.
For their comments on the list and his detailed analysis and simulations of SCTP, Rob Brennan and Thomas Curran.
| TOC |
| [1] | Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. |
| [2] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [3] | Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. |
| TOC |
| Randall R. Stewart | |
| Cisco Systems, Inc. | |
| 8725 West Higgins Road | |
| Suite 300 | |
| Chicago, IL 60631 | |
| USA | |
| Phone: | |
| EMail: | rrs@cisco.com |
| Lyndon Ong | |
| Ciena Systems | |
| 10480 Ridgeview Ct | |
| Cupertino, CA 95014 | |
| USA | |
| Phone: | |
| EMail: | lyong@ciena.com |
| Ivan Arias-Rodriguez | |
| Nokia Research Center | |
| PO Box 407 | |
| FIN-00045 Nokia Group | |
| Finland | |
| Phone: | |
| EMail: | ivan.arias-rodriguez@nokia.com |
| Kacheong Poon | |
| Sun Microsysystems, Inc. | |
| 901 San Antonio Road | |
| Palo Alto, CA 94303 | |
| USA | |
| Phone: | |
| EMail: | kacheong.poon@sun.com |
| Phillip T. Conrad | |
| Temple University | |
| CIS Department | |
| Room 303, Computer Building (038-24) | |
| 1805 N. Broad St. | |
| Philadelphia, PA 19122 | |
| US | |
| Phone: | +1 215 204 7910 |
| EMail: | conrad@acm.org |
| URI: | http://www.cis.temple.edu/~conrad |
| Armando L. Caro Jr. | |
| Department of Computer & Information Sciences University of Delaware | |
| 103 Smith Hall | |
| Newark, DE 19716 | |
| USA | |
| Phone: | |
| EMail: | acaro@cis.udel.edu |
| Michael Tuexen | |
| Siemens AG | |
| ICN WN CC SE 7 | |
| D-81359 Munich | |
| Germany | |
| Phone: | |
| EMail: | Michael.Tuexen@icn.siemens.de |
| TOC |
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society.