most, the lesser of 1) the total size of the previously
outstanding DATA chunk(s) acknowledged, and 2) the destination’s
path MTU. This upper bound protects against the ACK-Splitting
attack outlined in [SAVAGE99].
---------
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
2.14.3. Solution Description
The above changes strengthen the rules and make it much more apparent
as to the need to block cwnd growth when the full cwnd is not being
utilized. The changes also apply cwnd degradation without
introducing the need for complex special case code.
2.15. Window Probes in SCTP
2.15.1. Description of the Problem
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.
2.15.2. Text Changes to the Document
---------
Old text: (Section 6.2)
---------
The SCTP endpoint MUST always acknowledge the receipt 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
any new incoming DATA chunk with a TSN larger than the largest TSN
received so far. If the new incoming DATA chunk holds a TSN value
less than the largest TSN received so far, then the receiver SHOULD
drop the largest TSN held for reordering and accept the new incoming
DATA chunk. In either case, if such a DATA chunk is dropped, the
receiver MUST immediately send back a SACK with the current receive
window showing only DATA chunks received and accepted so far. The
dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
not accepted. The receiver MUST also have an algorithm for
advertising its receive window to avoid receiver silly window
syndrome (SWS), as described in RFC 813. The algorithm can be
similar to the one described in Section 4.2.3.3 of RFC 1122.
---------
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’s having been lost in transit from the data
receiver to the data sender.
When the receiver’s advertised window is zero, this probe is
called a zero window probe. Note that a zero window probe
SHOULD only be sent when all outstanding DATA chunks have
been cumulatively acknowledged and no DATA chunks are in
flight. Zero window probing MUST be supported.
If the sender continues to receive new packets from the receiver
while doing zero window probing, the unacknowledged window probes
should not increment the error counter for the association or any
destination transport address.This is because the receiver MAY
keep its window closed for an indefinite time. Refer to
Section 6.2 on the receiver behavior when it advertises a zero
window. The sender SHOULD send the first zero window probe after
1 RTO when it detects that the receiver has closed its window
and SHOULD increase the probe interval exponentially afterwards.
Also note that the cwnd SHOULD be adjusted according to
Section 7.2.1. Zero window probing does not affect the
calculation of cwnd.
The sender MUST also have an algorithm for sending new DATA chunks
to avoid silly window syndrome (SWS) as described in RFC 813. The
algorithm can be similar to the one described in Section 4.2.3.4
of RFC 1122.
2.15.3. Solution Description
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.
2.16. Fragmentation and Path MTU Issues
2.16.1. Description of the Problem
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 RFC 2960 [5], Section 6.9, was never meant to
restrict an implementations API from this behavior.
2.16.2. Text Changes to the Document
---------
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
it 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.
2.16.3. Solution Description
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.
2.17. Initial Value of the Cumulative TSN Ack
2.17.1. Description of the Problem
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.
2.17.2. Text Changes to the Document
---------
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 peer’s Initial TSN minus
one.
2.17.3. Solution Description
This change clearly states what the initial value will be for a SACK
sender.
2.18. Handling of Address Parameters within the INIT or INIT-ACK
2.18.1. Description of the Problem
The current description on handling address parameters contained
within the INIT and INIT-ACK does not fully describe a requirement
for their handling.
2.18.2. Text Changes to the Document
---------
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 MUST derive and record all the
transport addresses from the received chunk AND the source IP
address that sent the INIT or INIT ACK. The transport addresses
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) An INIT or INIT ACK chunk MUST be treated as belonging
to an already established association (or one in the
process of being established) if the use of any of the
valid address parameters contained within the chunk
would identify an existing TCB.
2.18.3. Solution description
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 (for example) not be able to recognize an INIT chunk coming
from an already established association that adds new addresses (see
Section 2.6) or an incoming INIT ACK chunk sent from a source address
different from the destination address used to send the INIT chunk.
2.19. Handling of Stream Shortages
2.19.1. Description of the Problem
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.
2.19.2. Text Changes to the Document
---------
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 MUST
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 MUST 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.
2.19.3. Solution Description
The above changes take the decision to ABORT out of the realm of the
SCTP stack and place it into the user’s hands.
2.20. Indefinite Postponement
2.20.1. Description of the Problem
The current RFC does not provide any guidance on the assignment of
TSN sequence numbers to outbound messages nor reception of these
messages. This could lead to a possible indefinite postponement.
2.20.2. Text Changes to the Document
---------
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 Acknowledgement 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; and
(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. Acknowledgement on Receipt of DATA Chunks
2.20.3. Solution Description
The above wording clarifies how TSNs SHOULD be assigned by the
sender.
2.21. User-Initiated Abort of an Association
2.21.1. Description of the Problem
It is not possible for an upper layer to abort the association and
provide the peer with an indication of why the association is
aborted.
2.21.2. Text changes to the document
Some of the changes given here already include changes suggested in
Section 2.6 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 that are sent
because of an upper layer request. The upper layer can specify
an Upper Layer Abort Reason that 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 MUST
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, a 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 MUST apply the special Verification
Tag check rules described in Section 8.5.1.
After checking the Verification Tag, the receiving endpoint MUST
remove the association from its record and SHOULD report the
termination to its upper layer. If a User-Initiated Abort error
cause is present in the ABORT chunk, the Upper Layer Abort Reason
SHOULD 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.
---------
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.