draft-ietf-tsvwg-sctpimpguide-00.txt   draft-ietf-tsvwg-sctpimpguide-01.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Request for Comments: 2960 Cisco Systems Request for Comments: 2960 Cisco Systems
Category: Internet Draft L. Ong Category: Internet Draft L. Ong
Ciena Systems Ciena Systems
Ivan Arias Rodriguez
Nokia
June 8 2001 June 29 2001
SCTP Implementors Guide SCTP Implementors Guide
draft-ietf-tsvwg-sctpimpguide-00.txt draft-ietf-tsvwg-sctpimpguide-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 6 skipping to change at page 2, line 8
Table of Contents Table of Contents
1. Introduction......................................... 2 1. Introduction......................................... 2
1.1 Conventions....................................... 2 1.1 Conventions....................................... 2
2. Corrections to RFC2960............................... 2 2. Corrections to RFC2960............................... 2
2.1 Incorrect error type during chunk processing....... 2 2.1 Incorrect error type during chunk processing....... 2
2.2 Parameter processing issue......................... 3 2.2 Parameter processing issue......................... 3
2.3 Padding issues.................................... 4 2.3 Padding issues.................................... 4
2.4 Parameter types across all chunk type.............. 5 2.4 Parameter types across all chunk type.............. 5
2.5 Stream parameter clarification..................... 6 2.5 Stream parameter clarification..................... 7
2.6 Restarting association security issue.............. 8 2.6 Restarting association security issue.............. 8
2.7 Implicit ability to exceed cwnd by PMTU-1 bytes....10 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes....12
2.8 Issues with Fast Retransmit........................11 2.8 Issues with Fast Retransmit........................13
2.9 Issues with Heartbeating and failure detection.....14 2.9 Issues with Heartbeating and failure detection.....17
2.10 Security interactions with firewalls..............16 2.10 Security interactions with firewalls..............19
3. Acknowledgments......................................17 2.11 Shutdown ambiguity................................19
4. Authors' Addresse....................................17 2.12 Inconsistency in ABORT processing.................21
5. References...........................................18 3. Acknowledgments......................................22
6. Bibliography.........................................18 4. Authors' Addresses...................................22
5. References...........................................23
6. Bibliography.........................................23
1. Introduction 1. Introduction
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
May 2001 for the Stream Control Transmission Protocol (SCTP) May 2001 for the Stream Control Transmission Protocol (SCTP)
[RFC2960]. These defects may be of an editorial or technical nature. [RFC2960]. These defects may be of an editorial or technical nature.
This document may be thought of as a companion document to be This document may be thought of as a companion document to be
used in the implementation of SCTP. used in the implementation of SCTP.
This document updates RFC2960 and text within this document, where This document updates RFC2960 and text within this document, where
skipping to change at page 4, line 17 skipping to change at page 4, line 20
It was always the intent to stop processing at the level one It was always the intent to stop processing at the level one
was at in an unknown chunk or parameter with the upper bit 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 set to 0. Thus if you are processing a chunk, you should drop
the packet. If you are processing a parameter, you should the packet. If you are processing a parameter, you should
drop the chunk. drop the chunk.
2.3 Padding issues 2.3 Padding issues
2.3.1 Description of the problem 2.3.1 Description of the problem
A problem was found in that when a Chunk was composed of A problem was found in that when a Chunk terminated in a
only TLV parameters. If the last TLV was not on an even TLV parameter. If this last TLV was not on a 32 bit
4 byte boundary, there was confusion as to if the last boundary (as required), there was confusion as to if the last
padding was included in the chunk length. padding was included in the chunk length.
2.3.2 Text changes to the document 2.3.2 Text changes to the document
--------- ---------
Old text: (Section 3.2) 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 Chunk Value: variable length
The Chunk Value field contains the actual information to be The Chunk Value field contains the actual information to be
transferred in the chunk. The usage and format of this field is transferred in the chunk. The usage and format of this field is
dependent on the Chunk Type. dependent on the Chunk Type.
The total length of a chunk (including Type, Length and Value fields) 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 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 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. bytes and this padding is not included in the chunk length field.
skipping to change at page 4, line 55 skipping to change at page 5, line 15
--------- ---------
New text: (Section 3.2) New text: (Section 3.2)
--------- ---------
Chunk Length: 16 bits (unsigned integer) Chunk Length: 16 bits (unsigned integer)
This value represents the size of the chunk in bytes including the This value represents the size of the chunk in bytes including the
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length 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 field will be set to 4. The Chunk Length field does not count any
padding. chunk padding.
Chunks (including Type, Length and Value fields) are padded out Chunks (including Type, Length and Value fields) are padded out
by the sender with all zero bytes to be a multiple of 4 bytes 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. long. This padding MUST NOT be more than 3 bytes in total.
The Chunk Length value does not include terminating padding The Chunk Length value does not include terminating padding
of the Chunk. However, it does include padding of any variable of the Chunk. However, it does include padding of any variable
length parameter except the last parameter in the Chunk. The length parameter except the last parameter in the Chunk. The
receiver MUST ignore the padding. receiver MUST ignore the padding.
Note: A robust implementation should accept the Chunk whether Note: A robust implementation should accept the Chunk whether
or not the final padding has been included in the Chunk Length. 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.
2.3.3 Solution description 2.3.3 Solution description
The above text makes clear that the padding is neither included The above text makes clear that the padding of the last parameter is
in the chunk length or parameter length in such a case. 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.
2.4 Parameter types across all chunk types 2.4 Parameter types across all chunk types
2.4.1 Description of the problem 2.4.1 Description of the problem
A problem was noted when multiple errors are needed A problem was noted when multiple errors are needed
to be sent regarding unknown or unrecognized parameters. to be sent regarding unknown or unrecognized parameters.
Since often times the error type does not hold the chunk Since often times the error type does not hold the chunk
type field, it may becomes difficult to tell which error type field, it may become difficult to tell which error
was associated with which chunk. was associated with which chunk.
2.4.2 Text changes to the document 2.4.2 Text changes to the document
--------- ---------
Old text: (Section 3.2.1) Old text: (Section 3.2.1)
--------- ---------
The actual SCTP parameters are defined in the specific SCTP chunk The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are sections. The rules for IETF-defined parameter extensions are
defined in Section 13.2. defined in Section 13.2.
--------- ---------
New text: (Section 3.2.1) New text: (Section 3.2.1)
--------- ---------
The actual SCTP parameters are defined in the specific SCTP chunk The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are sections. The rules for IETF-defined parameter extensions are
skipping to change at page 5, line 54 skipping to change at page 6, line 21
The actual SCTP parameters are defined in the specific SCTP chunk The actual SCTP parameters are defined in the specific SCTP chunk
sections. The rules for IETF-defined parameter extensions are sections. The rules for IETF-defined parameter extensions are
defined in Section 13.2. Note that a parameter value MUST be unique defined in Section 13.2. Note that a parameter value MUST be unique
across all chunks. For example, the parameter value '5' is used to across all chunks. For example, the parameter value '5' is used to
represent an IPv4 address (see section 3.3.2). The value '5' then represent an IPv4 address (see section 3.3.2). The value '5' then
is reserved across all chunks to represent an IPv4 address and is reserved across all chunks to represent an IPv4 address and
MUST NOT be reused with a different meaning in any other chunk. MUST NOT be reused with a different meaning in any other chunk.
--------- ---------
Old text: Old text: (Section 13.2)
--------- ---------
13.2 IETF-defined Chunk Parameter Extension 13.2 IETF-defined Chunk Parameter Extension
The assignment of new chunk parameter type codes is done through an The assignment of new chunk parameter type codes is done through an
IETF Consensus action as defined in [RFC2434]. Documentation of the IETF Consensus action as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information: chunk parameter MUST contain the following information:
a) Name of the parameter type. a) Name of the parameter type.
b) Detailed description of the structure of the parameter field. b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value This structure MUST conform to the general type-length-value
skipping to change at page 6, line 24 skipping to change at page 6, line 44
format described in Section 3.2.1. format described in Section 3.2.1.
c) Detailed definition of each component of the parameter value. c) Detailed definition of each component of the parameter value.
d) Detailed description of the intended use of this parameter type, d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple and an indication of whether and under what circumstances multiple
instances of this parameter type may be found within the same instances of this parameter type may be found within the same
chunk. chunk.
--------- ---------
New text: New text: (Section 13.2)
--------- ---------
13.2 IETF-defined Chunk Parameter Extension 13.2 IETF-defined Chunk Parameter Extension
The assignment of new chunk parameter type codes is done through an The assignment of new chunk parameter type codes is done through an
IETF Consensus action as defined in [RFC2434]. Documentation of the IETF Consensus action as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information: chunk parameter MUST contain the following information:
a) Name of the parameter type. a) Name of the parameter type.
skipping to change at page 7, line 9 skipping to change at page 7, line 28
what a parameter means based on context. The trade off for what a parameter means based on context. The trade off for
this is a smaller parameter space i.e. 65,535 parameters this is a smaller parameter space i.e. 65,535 parameters
versus 65,535 * Number-of-chunks. versus 65,535 * Number-of-chunks.
2.5 Stream parameter clarification 2.5 Stream parameter clarification
2.5.1 Description of the problem 2.5.1 Description of the problem
A problem was found where the specification is unclear A problem was found where the specification is unclear
on the legality of an endpoint asking for more stream on the legality of an endpoint asking for more stream
resources then were allowed in the OS value of the INIT. resources than were allowed in the OS value of the INIT.
In particular the value in the INIT-ACK requested in In particular the value in the INIT ACK requested in
its MIS value was larger than the OS value received in its MIS value was larger than the OS value received in
the INIT chunk. This behavior is illegal yet it was the INIT chunk. This behavior is illegal yet it was
unspecified in [RFC2960]. unspecified in [RFC2960].
2.5.2 Text changes to the document 2.5.2 Text changes to the document
--------- ---------
Old text: (Section 3.3.3) Old text: (Section 3.3.3)
--------- ---------
skipping to change at page 7, line 37 skipping to change at page 8, line 4
Note: There is no negotiation of the actual number of streams but Note: There is no negotiation of the actual number of streams but
instead the two endpoints will use the min(requested, offered). instead the two endpoints will use the min(requested, offered).
See Section 5.1.1 for details. See Section 5.1.1 for details.
Note: A receiver of an INIT ACK with the MIS value set to 0 Note: A receiver of an INIT ACK with the MIS value set to 0
SHOULD destroy the association discarding its TCB. SHOULD destroy the association discarding its TCB.
--------- ---------
New text: (Section 3.3.3) New text: (Section 3.3.3)
--------- ---------
Number of Inbound Streams (MIS) : 16 bits (unsigned integer) Number of Inbound Streams (MIS) : 16 bits (unsigned integer)
Defines the maximum number of streams the sender of this INIT ACK Defines the maximum number of streams the sender of this INIT ACK
chunk allows the peer end to create in this association. The chunk allows the peer end to create in this association. The
value 0 MUST NOT be used. value 0 MUST NOT be used.
Note: There is no negotiation of the actual number of streams but Note: There is no negotiation of the actual number of streams but
instead the two endpoints will use the min(requested, offered). instead the two endpoints will use the min(requested, offered).
See Section 5.1.1 for details. The Number of Inbound Streams See Section 5.1.1 for details. The Number of Inbound Streams
sent in the INIT-ACK MUST NOT be greater than the value found sent in the INIT ACK MUST NOT be greater than the value found
in the number of outbound streams received in the INIT. in the number of outbound streams received in the INIT.
Note: A receiver of an INIT ACK with the MIS value set to 0 Note: A receiver of an INIT ACK with the MIS value set to 0
SHOULD destroy the association discarding its TCB. SHOULD destroy the association discarding its TCB.
2.5.3 Solution description 2.5.3 Solution description
The change in wording, above, changes it so that a responder The change in wording, above, changes it so that a responder
to an INIT chunk does not specify more streams in it's to an INIT chunk does not specify more streams in it's
MIS value then was represented to it in the OS value i.e. MIS value then was represented to it in the OS value i.e.
its maximum. its maximum.
2.6 Restarting association security issue 2.6 Restarting association security issue
2.6.1 Description of the problem 2.6.1 Description of the problem
A security problem was found when a restart occurs. It is A security problem was found when a restart occurs. It is
skipping to change at page 8, line 53 skipping to change at page 9, line 18
Cause-specific Information: variable length Cause-specific Information: variable length
This field carries the details of the error condition. This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. 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 Guidelines for the IETF to define new error cause values are
discussed in Section 13.3. discussed in Section 13.3.
--------- ---------
New text: New text: (Section 3.3.10)
--------- ---------
Cause Code Cause Code
Value Cause Code Value Cause Code
--------- ---------------- --------- ----------------
1 Invalid Stream Identifier 1 Invalid Stream Identifier
2 Missing Mandatory Parameter 2 Missing Mandatory Parameter
3 Stale Cookie Error 3 Stale Cookie Error
4 Out of Resource 4 Out of Resource
5 Unresolvable Address 5 Unresolvable Address
skipping to change at page 9, line 32 skipping to change at page 9, line 50
Cause-specific Information: variable length Cause-specific Information: variable length
This field carries the details of the error condition. This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP. 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 Guidelines for the IETF to define new error cause values are
discussed in Section 13.3. discussed in Section 13.3.
--------- ---------
New text: (Note no old text, new error added) 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) 3.3.10.11 Restart of an association with new addresses (11)
Cause of error Cause of error
-------------- --------------
Restart of an association with new addresses: A COOKIE ECHO was Restart of an association with new addresses: A INIT was
received on an existing association. But the COOKIE ECHO added received on an existing association. But the INIT added
addresses to the association that were previously NOT part addresses to the association that were previously NOT part
of the association. The New addresses are listed in the of the association. The New addresses are listed in the
error code. This ERROR is normally sent as part of an ABORT error code. This ERROR is normally sent as part of an ABORT
refusing the Cookie Echo (see section 5.2.4). refusing the Cookie Echo (see section 5.2.4).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable | | Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs / / New Address TLVs /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--------- ---------
Old text: (Section 5.2.4) Old text: (Section 5.2.1)
--------- ---------
All the congestion control parameters (e.g., cwnd, ssthresh) Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an
related to this peer MUST be reset to their initial values (see endpoint MUST respond with an INIT ACK using the same parameters it
Section 6.2.1). sent in its original INIT chunk (including its Initiation Tag,
unchanged). These original parameters are combined with those from
After this the endpoint shall enter the ESTABLISHED state. 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.4) New text: (Section 5.2.1)
--------- ---------
All the congestion control parameters (e.g., cwnd, ssthresh) Upon receipt of an INIT in the COOKIE-WAIT state, an
related to this peer MUST be reset to their initial values (see endpoint MUST respond with an INIT ACK using the same parameters it
Section 6.2.1). 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.
If the cookie indicates that a new address(es) have been added Upon receipt of an INIT in the COOKIE-ECHOED state, an
to a restarting association, then the entire cookie MUST be discarded. endpoint MUST respond with an INIT ACK using the same parameters it
An ABORT MUST be sent that SHOULD include the error 'restart sent in its original INIT chunk (including its Initiation Tag,
of an association with new addresses'. The error SHOULD list the 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. addresses that were added to the restarting association.
This error should also list the TLV(s) with the new address(es) When responding in either state (COOKIE-WAIT or COOKIE-ECHOED)
that was/were not present in the old association. This would allow with an INIT ACK the original parameters are combined with those
a true restarting association to go through a recovery procedure from the newly received INIT chunk. The endpoint shall also generate a
(if it desired) to bring back the association. State Cookie with the INIT ACK. The endpoint uses the parameters
sent in its INIT to calculate the State Cookie.
After this the endpoint shall enter the ESTABLISHED state. ---------
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.
---------
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 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.
2.6.3 Solution description 2.6.3 Solution description
A new error code is being added and specific instructions A new error code is being added and specific instructions to send
to send back an ABORT to a new association in a restart back an ABORT to a new association in a restart case or collision
case where new addresses have been added. The error code case, where new addresses have been added. The error code can be
can be used by a legitimate restart to inform the endpoint used by a legitimate restart to inform the endpoint that it has made
that it has made a software error in adding a new address. a software error in adding a new address. The endpoint then can
The endpoint then can choose to wait until the OOTB ABORT choose to wait until the OOTB ABORT tears down the old association,
tears down the old association, or restart without the or restart without the new address.
new address.
2.7 Implicit ability to exceed cwnd by PMTU-1 bytes 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes
2.7.1 Description of the problem 2.7.1 Description of the problem
Some implementations were having difficulty growing there Some implementations were having difficulty growing there
cwnd. This was due to an improper enforcement of the congestion cwnd. This was due to an improper enforcement of the congestion
control rules. The rules, as written, provided for a slop control rules. The rules, as written, provided for a slop
over of the cwnd value. Without this slop over the sender over of the cwnd value. Without this slop over the sender
would appear to NOT be using its full cwnd value and thus would appear to NOT be using its full cwnd value and thus
skipping to change at page 11, line 21 skipping to change at page 13, line 4
New text: (Section 6.1) New text: (Section 6.1)
--------- ---------
B) At any given time, the sender MUST NOT transmit new data to a 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 given transport address if it has cwnd or more bytes of data
outstanding to that transport address. The sender may exceed outstanding to that transport address. The sender may exceed
cwnd by up to (PMTU-1) bytes on a new transmission if the cwnd cwnd by up to (PMTU-1) bytes on a new transmission if the cwnd
is not currently exceeded. is not currently exceeded.
2.7.3 Solution description 2.7.3 Solution description
The text changes make clear the ability to go over the cwnd value The text changes make clear the ability to go over the cwnd value
by no more than (PMTU-1) bytes. by no more than (PMTU-1) bytes.
2.8 Issues with Fast Retransmit 2.8 Issues with Fast Retransmit
2.8.1 Description of the problem 2.8.1 Description of the problem
A problem was found in the current specification of fast retransmit. A problem was found in the current specification of fast retransmit.
In particular in a high bandwidth * delay network. The current wording In particular in a high bandwidth * delay network. The current wording
did require GAP ACK blocks to be sent, even though they are essential 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 to the workings of SCTP's congestion control. Also the specification
left unclear how to handle the fast retransmit cycle. Waiting to left unclear how to handle the fast retransmit cycle. Waiting to
retransmit a TSN needing fast retransmit. Also no limit was placed retransmit a TSN needing fast retransmit. Also no limit was placed
on how many times a TSN could be fast retransmitted. When recovering on how many times a TSN could be fast retransmitted. When recovering
from a fast retransmit no burst limit was applied as well to prevent from a fast retransmit no burst limit was applied as well to prevent
an rwnd clamp down from causing an excessive burst of traffic. an rwnd clamp down from causing an excessive burst of traffic.
2.8.2 Text changes to the document 2.8.2 Text changes to the document
--------- ---------
skipping to change at page 12, line 21 skipping to change at page 13, line 55
chunk format. In particular, the SCTP endpoint MUST fill in the chunk format. In particular, the SCTP endpoint MUST fill in the
Cumulative TSN Ack field to indicate the latest sequential TSN (of a Cumulative TSN Ack field to indicate the latest sequential TSN (of a
valid DATA chunk) it has received. Any received DATA chunks with TSN 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 greater than the value in the Cumulative TSN Ack field MUST also be
reported in the Gap Ack Block fields. reported in the Gap Ack Block fields.
--------- ---------
Old text: (Section 7.2.4) 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 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address to constraint of the path MTU of the destination transport address
to which the packet is being sent. Call this value K. Retransmit to which the packet is being sent. Call this value K. Retransmit
those K DATA chunks in a single packet. those K DATA chunks in a single packet.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that retransmitting the first outstanding DATA chunk sent to that
address. address.
skipping to change at page 12, line 49 skipping to change at page 14, line 40
consecutive SACK reporting the TSN hole. After reaching 4 and consecutive SACK reporting the TSN hole. After reaching 4 and
starting the fast retransmit procedure, the counter resets to 0. starting the fast retransmit procedure, the counter resets to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size. no adjustment to the congestion control window size.
--------- ---------
New text: (Section 7.2.4) 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 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address to constraint of the path MTU of the destination transport address
to which the packet is being sent. Call this value K. Retransmit to which the packet is being sent. Call this value K. Retransmit
those K DATA chunks in a single packet. When a Fast 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 is being performed the sender SHOULD ignore the value of cwnd and
SHOULD NOT delay retransmission. SHOULD NOT delay retransmission.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that retransmitting the first outstanding DATA chunk sent to that
address. address.
5) Mark the DATA chunk(s) as being fast retransmitted and thus 5) Mark the DATA chunk(s) as being fast retransmitted and thus
ineligible for a subsequent fast retransmit until after the ineligible for a subsequent fast retransmit.
T3-rxt timer expires.
Note: Before the above adjustments, if the received SACK also Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack 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 Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first. must be applied first.
A straightforward implementation of the above keeps a counter for A straightforward implementation of the above is as follows:
each TSN hole reported by a SACK. The counter increments for each
consecutive SACK reporting the TSN hole. After reaching 4 and M1) Each time a new DATA chunk is transmited set the
starting the fast retransmit procedure, the counter resets to 0. 'TSN.Missing.Report' count for that TSN to 0. The
'TSN.Missing.Report' count will be used to determine
missing segments and when to fast retransmit.
M2) Each time a SACK arrives reporting 'Stray DATA chunk(s)'
record the highest new TSN reported as newly acknowledged,
call this value 'HighestTSNinSack'. A newly acknowledged
DATA chunk is one not previously acknowledged in a SACK.
A 'Stray Data chunk', is 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.
M3) Examine all 'Unacknowledged TSN's', if the TSN number
of an 'Unaknowledged TSN' is smaller than the 'HigestTSNinSack'
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 procuedure
(steps 2-5 above).
M5) If a T3-rxt timer expires,the 'TSN.Missing.Report' of all
affected TSNs is set to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size. no adjustment to the congestion control window size.
Upon acknowledgment of a DATA chunk that has been fast retransmitted, Upon acknowledgment of a DATA chunk that has been fast retransmitted,
the protocol parameter 'Max.Burst' MUST be applied to limit the protocol parameter 'Max.Burst' MUST be applied to limit
how many SCTP packets may be sent upon the completion of SACK how many SCTP packets may be sent upon the completion of SACK
processing. processing.
--------- ---------
Old text: Old text: (Section 14)
--------- ---------
14. Suggested SCTP Protocol Parameter Values 14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED: The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds RTO.Initial - 3 seconds
RTO.Min - 1 second RTO.Min - 1 second
RTO.Max - 60 seconds RTO.Max - 60 seconds
RTO.Alpha - 1/8 RTO.Alpha - 1/8
RTO.Beta - 1/4 RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address) Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds HB.interval - 30 seconds
--------- ---------
New text: New text: (Section 14)
--------- ---------
14. Suggested SCTP Protocol Parameter Values 14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED: The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds RTO.Initial - 3 seconds
RTO.Min - 1 second RTO.Min - 1 second
RTO.Max - 60 seconds RTO.Max - 60 seconds
Max.Burst - 4 packets Max.Burst - 4 packets
RTO.Alpha - 1/8 RTO.Alpha - 1/8
RTO.Beta - 1/4 RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address) Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds HB.interval - 30 seconds
2.8.3 Solution description 2.8.3 Solution description
The effect of the above wording changes is four-fold: The effect of the above wording changes are as follows:
- It requires with a MUST the sending of GAP Ack blocks - It requires with a MUST the sending of GAP Ack blocks
instead of the current [RFC2960] SHOULD. instead of the current [RFC2960] SHOULD.
- It allows a TSN being Fast Retransmitted (FR) to be sent - It allows a TSN being Fast Retransmitted (FR) to be sent
only once via FR until a subsequent timer expiration. only once via FR.
- It ends the delay in awaiting for the flight size to - It ends the delay in awaiting for the flight size to
drop when a TSN is identified ready to FR. drop when a TSN is identified ready to FR.
- It applies a Max.Burst parameter to prevent a FR from - It applies a Max.Burst parameter to prevent a FR from
flooding the network with packets after rwnd has been flooding the network with packets after rwnd has been
clamped to '0' for a period of time. clamped to '0' for a period of time.
These changes will effectively allow SCTP to follow - It changes the way chunks are marked during fast retransmit,
the same model as TCP in the handling of Fast Retransmit. so that only new reports are counted (using M1-M4 above).
These changes will effectively allow SCTP to follow a
similar model as TCP+SACK in the handling of Fast Retransmit.
2.9 Issues with Heartbeating and failure detection 2.9 Issues with Heartbeating and failure detection
2.9.1 Description of the problem 2.9.1 Description of the problem
Four basic problems have been discovered with the Four basic problems have been discovered with the
current heartbeat procedures. current heartbeat procedures.
o The current specification does not specify that you o The current specification does not specify that you
should count a failed heartbeat as an error against the should count a failed heartbeat as an error against the
skipping to change at page 14, line 56 skipping to change at page 17, line 32
o The current specification is un-specific as to when o The current specification is un-specific as to when
you should respond to heartbeats. you should respond to heartbeats.
o When responding to a Heartbeat it is unclear what to o When responding to a Heartbeat it is unclear what to
do if more than a single TLV is present. do if more than a single TLV is present.
2.9.2 Text changes to the document 2.9.2 Text changes to the document
--------- ---------
Old text: Old text: (Section 8.1)
--------- ---------
8.1 Endpoint Failure Detection 8.1 Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (including retransmissions to all the retransmissions to its peer (including retransmissions to all the
destination transport addresses of the peer if it is multi-homed). destination transport addresses of the peer if it is multi-homed).
If the value of this counter exceeds the limit indicated in the If the value of this counter exceeds the limit indicated in the
protocol parameter 'Association.Max.Retrans', the endpoint shall protocol parameter 'Association.Max.Retrans', the endpoint shall
consider the peer endpoint unreachable and shall stop transmitting consider the peer endpoint unreachable and shall stop transmitting
any more data to it (and thus the association enters the CLOSED any more data to it (and thus the association enters the CLOSED
state). In addition, the endpoint shall report the failure to the state). In addition, the endpoint shall report the failure to the
upper layer, and optionally report back all outstanding user data upper layer, and optionally report back all outstanding user data
remaining in its outbound queue. The association is automatically remaining in its outbound queue. The association is automatically
closed when the peer endpoint becomes unreachable. closed when the peer endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer 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 endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint. HEARTBEAT-ACK is received from the peer endpoint.
--------- ---------
New text: New text: (Section 8.1)
--------- ---------
8.1 Endpoint Failure Detection 8.1 Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (including retransmissions to all the retransmissions to its peer (this includes retransmissions to all the
destination transport addresses of the peer if it is multi-homed, destination transport addresses of the peer if it is multi-homed),
and unacknowledged HEARTBEAT Chunks). If the value of this counter including unacknowledged HEARTBEAT Chunks. If the value of this
exceeds the limit indicated in the protocol parameter counter exceeds the limit indicated in the protocol parameter
'Association.Max.Retrans', the endpoint shall consider the peer 'Association.Max.Retrans', the endpoint shall consider the peer
endpoint unreachable and shall stop transmitting any more data to it endpoint unreachable and shall stop transmitting any more data to it
(and thus the association enters the CLOSED state). In addition, (and thus the association enters the CLOSED state). In addition,
the endpoint shall report the failure to the upper layer, and the endpoint shall report the failure to the upper layer, and
optionally report back all outstanding user data remaining in its optionally report back all outstanding user data remaining in its
outbound queue. The association is automatically closed when the outbound queue. The association is automatically closed when the
peer endpoint becomes unreachable. peer endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer 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 endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint. HEARTBEAT-ACK is received from the peer endpoint.
--------- ---------
Old text: Old text: (Section 8.3)
--------- ---------
8.3 Path Heartbeat 8.3 Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the By default, an SCTP endpoint shall monitor the reachability of the
idle destination transport address(es) of its peer by sending a idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport HEARTBEAT chunk periodically to the destination transport
address(es). address(es).
--------- ---------
New text: New text: (Section 8.3)
--------- ---------
8.3 Path Heartbeat 8.3 Path Heartbeat
By default, an SCTP endpoint shall monitor the reachability of the By default, an SCTP endpoint shall monitor the reachability of the
idle destination transport address(es) of its peer by sending a idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport HEARTBEAT chunk periodically to the destination transport
address(es). HEARTBEAT sending MAY begin upon reaching the address(es). HEARTBEAT sending MAY begin upon reaching the
ESTABLISHED state, and is discontinued after sending either ESTABLISHED state, and is discontinued after sending either
SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST
respond to a HEARTBEAT with a HEARTBEAT-ACK after entering respond to a HEARTBEAT with a HEARTBEAT-ACK after entering
the COOKIE-SENT state up until reaching the CLOSED state. the COOKIE-SENT state (INIT sender) or the ESTABLISHED
state (INIT receiver), up until reaching the SHUTDOWN-SENT
state (SHUTDOWN sender) of the SHUTDOWN-ACK-SENT state
(SHUTDOWN receiver).
--------- ---------
Old text: (Section 8.3): Old text: (Section 8.3):
--------- ---------
The receiver of the HEARTBEAT should immediately respond with a The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the Heartbeat Information field copied HEARTBEAT ACK that contains the Heartbeat Information field copied
from the received HEARTBEAT chunk. from the received HEARTBEAT chunk.
--------- ---------
skipping to change at page 16, line 47 skipping to change at page 19, line 27
how to respond to a heartbeat with extra parameters, and clarifies how to respond to a heartbeat with extra parameters, and clarifies
the error counting procedures for the association. the error counting procedures for the association.
2.10 Security interactions with firewalls 2.10 Security interactions with firewalls
2.10.1 Description of the problem 2.10.1 Description of the problem
When dealing with firewalls it is advantageous to the firewall When dealing with firewalls it is advantageous to the firewall
to be able to properly determine the initial startup sequence to be able to properly determine the initial startup sequence
of a reliable transport protocol. With this in mind the of a reliable transport protocol. With this in mind the
following text is to added to SCTP's security section. following text is to be added to SCTP's security section.
2.10.2 Text changes to the document 2.10.2 Text changes to the document
--------- ---------
New text: (no old text, new section added) New text: (no old text, new section added)
--------- ---------
11.4 SCTP interactions with firewalls 11.4 SCTP interactions with firewalls
Per [RFC1858], it is helpful for some firewalls if they can inspect Per [RFC1858], it is helpful for some firewalls if they can inspect
just the first fragment of a fragmented SCTP packet and just the first fragment of a fragmented SCTP packet and
unambiguously determine whether it corresponds to an INIT chunk. unambiguously determine whether it corresponds to an INIT chunk.
Accordingly, we stress the requirements stated in 3.1 that (1) an 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 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 (2) a packet containing an INIT chunk MUST have a zero Verification
Tag. Furthermore, we require that the receiver of an INIT chunk Tag. Furthermore, we require that the receiver of an INIT chunk
MUST enforce these rules by silently discarding an arriving packet MUST enforce these rules by silently discarding an arriving packet
with an INIT chunk that is bundled with other chunks. with an INIT chunk that is bundled with other chunks.
2.11 Shutdown ambiguity
2.11.1 Description of the problem
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. Section 9.2 which
requires a SHUTDOWN chunk and a SACK chunk to be sent.
Along with this ambiguity there is a problem where in
a errant SHUTDOWN reciever may fail to stop accepting
user data.
2.11.2 Text changes to the document
---------
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
TNS 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 it 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.
2.11.3 Solution description
The above text clearifies 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.
2.12 Inconsistency in ABORT processing
2.12.1 Description of the problem
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.
2.12.2 Text changes to the document
---------
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.
2.12.3 Solution description
The above text change clearifies that the T bit must be set
before an implementation looks for the peers tag.
3. Acknowledgments 3. Acknowledgments
The authors would like to thank the following people that have The authors would like to thank the following people that have
provided comments and input for this document: provided comments and input for this document:
For their comments on the list, Atsushi Fukumoto. For their comments on the list, Atsushi Fukumoto.
For their participation in the RTP Bakeoff number 2 and all of their For their participation in the RTP Bakeoff number 2 and all of their
input, Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, input, Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss,
Manoj Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Manoj Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent
Glaude, Jon Berger, Dan Harrison, Sabina Torrente, Tomas Ort¨ Glaude, Jon Berger, Dan Harrison, Sabina Torrente, Tomas Ort¨
Mart¨n, Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Mart¨n, Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben
Robinson, David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Robinson, David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan,
Melissa Campbell, Sujith Radhakrishnan, Michael Tuexen, Andreas Melissa Campbell, Sujith Radhakrishnan, Michael Tuexen, Andreas
Jungmaier, Mitch Miers, Fred Hasle, Oliver Mayor, Cliff Thomas, Jungmaier, Mitch Miers, Fred Hasle, Oliver Mayor, Cliff Thomas,
Jonathan Wood, Kacheong Poon, Sverre Slotte, Wang Xiaopeng, Ivan Jonathan Wood, Kacheong Poon, Sverre Slotte, Wang Xiaopeng,
Rodriguez, John Townsend, Harsh Bhondwe, Sandeep Mahajan, RCMonee, John Townsend, Harsh Bhondwe, Sandeep Mahajan, RCMonee,
Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep Balani, Biren Patel, Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep Balani, Biren Patel,
Qiaobing Xie, Karl Knutson, La Monte Yarroll, Gareth Keily, Ian Qiaobing Xie, Karl Knutson, La Monte Yarroll, Gareth Keily, Ian
Periam, Nathalie Mouellic, and Stan McClellan. Periam, Nathalie Mouellic, and Stan McClellan.
For their comments on the list and his detailed analysis and For their comments on the list and his detailed analysis and
simulations of SCTP. simulations of SCTP.
Rob Brennan and Thomas Curran. Rob Brennan and Thomas Curran.
4. Authors' Addresses 4. Authors' Addresses
skipping to change at page 18, line 4 skipping to change at page 22, line 52
USA USA
EMail: rrs@cisco.com EMail: rrs@cisco.com
Lyndon Ong Lyndon Ong
Ciena Systems Ciena Systems
10480 Ridgeview Ct 10480 Ridgeview Ct
Cupertino, CA 95014 Cupertino, CA 95014
EMail: lyong@ciena.com EMail: lyong@ciena.com
Ivan Arias Rodriguez Tel: +358-50-483-9494
Nokia Research Center EMail: ivan.arias-rodriguez@nokia.com
PO Box 407
FIN-00045 Nokia Group
Finland
5. References 5. References
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,
H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang,
and, V. Paxson, "Stream Control Transmission Protocol," RFC and, V. Paxson, "Stream Control Transmission Protocol," RFC
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/