draft-ietf-tsvwg-rfc4960-errata-01.txt   draft-ietf-tsvwg-rfc4960-errata-02.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Netflix, Inc. Internet-Draft Netflix, Inc.
Intended status: Informational M. Tuexen Intended status: Informational M. Tuexen
Expires: May 3, 2017 Muenster Univ. of Appl. Sciences Expires: January 4, 2018 Muenster Univ. of Appl. Sciences
M. Proshin M. Proshin
Ericsson Ericsson
October 30, 2016 July 3, 2017
RFC 4960 Errata and Issues RFC 4960 Errata and Issues
draft-ietf-tsvwg-rfc4960-errata-01.txt draft-ietf-tsvwg-rfc4960-errata-02.txt
Abstract Abstract
This document is a compilation of issues found since the publication This document is a compilation of issues found since the publication
of RFC4960 in September 2007 based on experience with implementing, of RFC4960 in September 2007 based on experience with implementing,
testing, and using SCTP along with the suggested fixes. This testing, and using SCTP along with the suggested fixes. This
document provides deltas to RFC4960 and is organized in a time based document provides deltas to RFC4960 and is organized in a time based
way. The issues are listed in the order they were brought up. way. The issues are listed in the order they were brought up.
Because some text is changed several times the last delta in the text Because some text is changed several times the last delta in the text
is the one which should be applied. In addition to the delta a is the one which should be applied. In addition to the delta a
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 3 3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 4
3.1. Path Error Counter Threshold Handling . . . . . . . . . . 3 3.1. Path Error Counter Threshold Handling . . . . . . . . . . 4
3.2. Upper Layer Protocol Shutdown Request Handling . . . . . 4 3.2. Upper Layer Protocol Shutdown Request Handling . . . . . 5
3.3. Registration of New Chunk Types . . . . . . . . . . . . . 5 3.3. Registration of New Chunk Types . . . . . . . . . . . . . 5
3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 6 3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 6
3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 7 3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 7
3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 8 3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 8
3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 9 3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 9
3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 10 3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 10
3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 11 3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 11
3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 17 3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 17
3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 18 3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 18
3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 18 3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 18
skipping to change at page 2, line 48 skipping to change at page 2, line 48
3.22. Increase of partial_bytes_acked in Congestion Avoidance . 31 3.22. Increase of partial_bytes_acked in Congestion Avoidance . 31
3.23. Inconsistency in Notifications Handling . . . . . . . . . 32 3.23. Inconsistency in Notifications Handling . . . . . . . . . 32
3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 36 3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 36
3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 38 3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 38
3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 39 3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 39
3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 41 3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 41
3.28. Window Updates After Receiver Window Opens Up . . . . . . 42 3.28. Window Updates After Receiver Window Opens Up . . . . . . 42
3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 43 3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 43
3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 45 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 45
3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 46 3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 46
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 47
5. Security Considerations . . . . . . . . . . . . . . . . . . . 47 3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 49
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 49
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 50
7.1. Normative References . . . . . . . . . . . . . . . . . . 48 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 52
7.2. Informative References . . . . . . . . . . . . . . . . . 48 3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 55
3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 56
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
5. Security Considerations . . . . . . . . . . . . . . . . . . . 58
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.1. Normative References . . . . . . . . . . . . . . . . . . 58
7.2. Informative References . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
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
the publishing of this document for [RFC4960] specifying the Stream the publishing of this document for [RFC4960] specifying the Stream
Control Transmission Protocol (SCTP). These defects may be of an Control Transmission Protocol (SCTP). These defects may be of an
editorial or technical nature. This document may be thought of as a editorial or technical nature. This document may be thought of as a
companion document to be used in the implementation of SCTP to companion document to be used in the implementation of SCTP to
clarify errors in the original SCTP document. clarify errors in the original SCTP document.
skipping to change at page 47, line 43 skipping to change at page 47, line 43
packets to transmit and particularly using the formula above, packets to transmit and particularly using the formula above,
cwnd SHOULD NOT be changed. cwnd SHOULD NOT be changed.
3.31.3. Solution Description 3.31.3. Solution Description
The new text clarifies that cwnd should not be changed when appling The new text clarifies that cwnd should not be changed when appling
the Max.Burst limit. This mitigates packet bursts related to the the Max.Burst limit. This mitigates packet bursts related to the
reception of SACK chunks, but not bursts related to an application reception of SACK chunks, but not bursts related to an application
sending a burst of user messages. sending a burst of user messages.
3.32. Reduction of RTO.Initial
3.32.1. Description of the Problem
[RFC4960] uses 3 seconds as the default value for RTO.Initial in
accordance with Section 4.3.2.1 of [RFC1122]. [RFC6298] updates
[RFC1122] and lowers the initial value of the retransmission timer
from 3 seconds to 1 second.
3.32.2. Text Changes to the Document
---------
Old text: (Section 15)
---------
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
HB.Max.Burst - 1
SACK.Delay - 200 milliseconds
---------
New text: (Section 15)
---------
The following protocol parameters are RECOMMENDED:
RTO.Initial - 1 second
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
HB.Max.Burst - 1
SACK.Delay - 200 milliseconds
3.32.3. Solution Description
The value RTO.Initial has been lowered to 1 second to be in tune with
[RFC6298].
3.33. Ordering of Bundled SACK and ERROR Chunks
3.33.1. Description of the Problem
When an SCTP endpoint receives a DATA chunk with an invalid stream
identifier it shall acknowledge it by sending a SACK chunk and
indicate that the stream identifier was invalid by sending an ERROR
chunk. These two chunks may be bundled. However, [RFC4960] requires
in case of bundling that the ERROR chunk follows the SACK chunk.
This restriction of the ordering is not necessary and might only
limit interoperability.
3.33.2. Text Changes to the Document
---------
Old text: (Section 6.5)
---------
Every DATA chunk MUST carry a valid stream identifier. If an
endpoint receives a DATA chunk with an invalid stream identifier, it
shall acknowledge the reception of the DATA chunk following the
normal procedure, immediately send an ERROR chunk with cause set to
"Invalid Stream Identifier" (see Section 3.3.10), and discard the
DATA chunk. The endpoint may bundle the ERROR chunk in the same
packet as the SACK as long as the ERROR follows the SACK.
---------
New text: (Section 6.5)
---------
Every DATA chunk MUST carry a valid stream identifier. If an
endpoint receives a DATA chunk with an invalid stream identifier, it
shall acknowledge the reception of the DATA chunk following the
normal procedure, immediately send an ERROR chunk with cause set to
"Invalid Stream Identifier" (see Section 3.3.10), and discard the
DATA chunk. The endpoint may bundle the ERROR chunk and the SACK Chunk
in the same packet.
3.33.3. Solution Description
The unnecessary restriction regarding the ordering of the SACK and
ERROR chunk has been removed.
3.34. Undefined Parameter Returned by RECEIVE Primitive
3.34.1. Description of the Problem
[RFC4960] provides a description of an abstract API. In the
definition of the RECEIVE primitive an optional parameter with name
"delivery number" is mentioned. However, no definition of this
parameter is given in [RFC4960] and the parameter is unnecessary.
3.34.2. Text Changes to the Document
---------
Old text: (Section 10.1)
---------
G) Receive
Format: RECEIVE(association id, buffer address, buffer size
[,stream id])
-> byte count [,transport address] [,stream id] [,stream sequence
number] [,partial flag] [,delivery number] [,payload protocol-id]
---------
New text: (Section 10.1)
---------
G) Receive
Format: RECEIVE(association id, buffer address, buffer size
[,stream id])
-> byte count [,transport address] [,stream id] [,stream sequence
number] [,partial flag] [,payload protocol-id]
3.34.3. Solution Description
The undefined parameter has been removed.
3.35. DSCP Changes
3.35.1. Description of the Problem
The upper layer can change the Differentiated Services Code Point
(DSCP) used for packets being sent. A change of the DSCP can result
in packets hitting different queues on the path and therefore the
congestion control should be initialized when the DSCP is changed by
the upper layer. This is not described in [RFC4960].
3.35.2. Text Changes to the Document
---------
New text: (Section 7.2.5)
---------
SCTP implementations MAY allow an application to configure the
Differentiated Services Code Point (DSCP) used for sending packets.
If a DSCP change might result in outgoing packets being queued in different
queues, the congestion control parameters for all affected destination
addresses MUST be reset to their initial values.
---------
Old text: (Section 10.1)
---------
M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id,
[,destination transport address,]
protocol parameter list)
-> result
This primitive allows the local SCTP to customize the protocol
parameters.
Mandatory attributes:
o association id - local handle to the SCTP association.
o protocol parameter list - the specific names and values of the
protocol parameters (e.g., Association.Max.Retrans; see Section
15) that the SCTP user wishes to customize.
---------
Old text: (Section 10.1)
---------
M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id,
[,destination transport address,]
protocol parameter list)
-> result
This primitive allows the local SCTP to customize the protocol
parameters.
Mandatory attributes:
o association id - local handle to the SCTP association.
o protocol parameter list - the specific names and values of the
protocol parameters (e.g., Association.Max.Retrans; see Section
15, or other parameters like the DSCP) that the SCTP user wishes
to customize.
3.35.3. Solution Description
Text describing the required action on DSCP changes has been added.
3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages
3.36.1. Description of the Problem
Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6
messages. The text explicitly describes the handling of ICMPv6
packets indicating reachability problems, but does not do the same
for the corresponding ICMPv4 packets.
3.36.2. Text Changes to the Document
---------
Old text: (Appendix C)
---------
ICMP1) An implementation MAY ignore all ICMPv4 messages where the
type field is not set to "Destination Unreachable".
ICMP2) An implementation MAY ignore all ICMPv6 messages where the
type field is not "Destination Unreachable", "Parameter
Problem",, or "Packet Too Big".
ICMP3) An implementation MAY ignore any ICMPv4 messages where the
code does not indicate "Protocol Unreachable" or
"Fragmentation Needed".
ICMP4) An implementation MAY ignore all ICMPv6 messages of type
"Parameter Problem" if the code is not "Unrecognized Next
Header Type Encountered".
ICMP5) An implementation MUST use the payload of the ICMP message (v4
or v6) to locate the association that sent the message to
which ICMP is responding. If the association cannot be found,
an implementation SHOULD ignore the ICMP message.
ICMP6) An implementation MUST validate that the Verification Tag
contained in the ICMP message matches the Verification Tag of
the peer. If the Verification Tag is not 0 and does NOT
match, discard the ICMP message. If it is 0 and the ICMP
message contains enough bytes to verify that the chunk type is
an INIT chunk and that the Initiate Tag matches the tag of the
peer, continue with ICMP7. If the ICMP message is too short
or the chunk type or the Initiate Tag does not match, silently
discard the packet.
ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4
"Fragmentation Needed", an implementation MAY process this
information as defined for PATH MTU discovery.
ICMP8) If the ICMP code is an "Unrecognized Next Header Type
Encountered" or a "Protocol Unreachable", an implementation
MUST treat this message as an abort with the T bit set if it
does not contain an INIT chunk. If it does contain an INIT
chunk and the association is in the COOKIE-WAIT state, handle
the ICMP message like an ABORT.
ICMP9) If the ICMPv6 code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter.
---------
New text: (Appendix C)
---------
ICMP1) An implementation MAY ignore all ICMPv4 messages where the
type field is not set to "Destination Unreachable".
ICMP2) An implementation MAY ignore all ICMPv6 messages where the
type field is not "Destination Unreachable", "Parameter
Problem",, or "Packet Too Big".
ICMP3) An implementation MAY ignore all ICMPv6 messages of type
"Parameter Problem" if the code is not "Unrecognized Next
Header Type Encountered".
ICMP4) An implementation MUST use the payload of the ICMP message (v4
or v6) to locate the association that sent the message to
which ICMP is responding. If the association cannot be found,
an implementation SHOULD ignore the ICMP message.
ICMP5) An implementation MUST validate that the Verification Tag
contained in the ICMP message matches the Verification Tag of
the peer. If the Verification Tag is not 0 and does NOT
match, discard the ICMP message. If it is 0 and the ICMP
message contains enough bytes to verify that the chunk type is
an INIT chunk and that the Initiate Tag matches the tag of the
peer, continue with ICMP7. If the ICMP message is too short
or the chunk type or the Initiate Tag does not match, silently
discard the packet.
ICMP6) If the ICMP message is either a v6 "Packet Too Big" or a v4
"Fragmentation Needed", an implementation MAY process this
information as defined for PATH MTU discovery.
ICMP7) If the ICMP code is an "Unrecognized Next Header Type
Encountered" or a "Protocol Unreachable", an implementation
MUST treat this message as an abort with the T bit set if it
does not contain an INIT chunk. If it does contain an INIT
chunk and the association is in the COOKIE-WAIT state, handle
the ICMP message like an ABORT.
ICMP8) If the ICMP code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter.
3.36.3. Solution Description
The text has been changed to not limit the processing of ICMPv4
packets with type "Destination Unreachable" by removing the third
rule. Furthermore, remove in the ninth rule the limitation to
ICMPv6.
3.37. Handling of Soft Errors
3.37.1. Description of the Problem
[RFC1122] defines the handling of soft errors and hard errors for
TCP. Appendix C of [RFC4960] only deals with hard errors.
3.37.2. Text Changes to the Document
---------
Old text: (Appendix C)
---------
ICMP8) If the ICMP code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter.
---------
New text: (Appendix C)
---------
ICMP8) If the ICMP code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter.
SCTP MAY provide information to the upper layer indicating the reception
of ICMP messages when reporting a network status change.
3.37.3. Solution Description
Text has been added allowing the SCTP to notify the application in
case of soft errors.
3.38. Honoring CWND
3.38.1. Description of the Problem
When using the slow start algorithm, SCTP increases the congestion
window only when it is being fully utilized. Since SCTP uses DATA
chunks and does not use the congestion window to fragment user
messages, this requires that some overbooking of the congestion
window is allowed.
3.38.2. Text Changes to the Document
---------
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 + (PMTU - 1) or more bytes of data
outstanding to that transport address. If data is available the
sender SHOULD exceed cwnd by up to (PMTU-1) bytes on a new data
transmission if the flightsize does not currently reach cwnd.
The breach of cwnd MUST constitute one packet only.
---------
Old text: (Section 7.2.1)
---------
o Whenever cwnd is greater than zero, the endpoint is allowed to
have cwnd bytes of data outstanding on that transport address.
---------
New text: (Section 7.2.1)
---------
o Whenever cwnd is greater than zero, the endpoint is allowed to
have cwnd bytes of data outstanding on that transport address.
A limited overbooking as described in B) of Section 6.1 should
be supported.
3.38.3. Solution Description
Text was added that to clarify how the CWND limit should be handled.
3.39. Zero Window Probing
3.39.1. Description of the Problem
The text describing zero window probing was not clearly handling the
case where the window was not zero, but too small for the next DATA
chunk to be transmitted. Even in this case, zero window probing has
to be performed to avoid deadlocks.
3.39.2. Text Changes to the Document
---------
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'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.
---------
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 smaller than the
size of the next DATA chunk; 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 has no buffer space, 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.
3.39.3. Solution Description
The terminology is used in a cleaner way.
4. IANA Considerations 4. IANA Considerations
This document does not require any actions from IANA. This document does not require any actions from IANA.
5. Security Considerations 5. Security Considerations
This document does not add any security considerations to those given This document does not add any security considerations to those given
in [RFC4960]. in [RFC4960].
6. Acknowledgments 6. Acknowledgments
The authors wish to thank Pontus Andersson, Eric W. Biederman, The authors wish to thank Pontus Andersson, Eric W. Biederman,
Cedric Bonnet, Lionel Morand, Jeff Morriss, Karen E. E. Nielsen, Cedric Bonnet, Lionel Morand, Jeff Morriss, Karen E. E. Nielsen,
Tom Petch and Julien Pourtet for their invaluable comments. Tom Petch, Julien Pourtet, and Michael Welzl for their invaluable
comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>. <http://www.rfc-editor.org/info/rfc4960>.
7.2. Informative References 7.2. Informative References
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000,
<http://www.rfc-editor.org/info/rfc2960>. <http://www.rfc-editor.org/info/rfc2960>.
[RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and
M. Tuexen, "Stream Control Transmission Protocol (SCTP) M. Tuexen, "Stream Control Transmission Protocol (SCTP)
Specification Errata and Issues", RFC 4460, Specification Errata and Issues", RFC 4460,
DOI 10.17487/RFC4460, April 2006, DOI 10.17487/RFC4460, April 2006,
<http://www.rfc-editor.org/info/rfc4460>. <http://www.rfc-editor.org/info/rfc4460>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<http://www.rfc-editor.org/info/rfc5681>. <http://www.rfc-editor.org/info/rfc5681>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Netflix, Inc. Netflix, Inc.
Chapin, SC 29036 Chapin, SC 29036
United States United States
Email: randall@lakerest.net Email: randall@lakerest.net
Michael Tuexen Michael Tuexen
Muenster University of Applied Sciences Muenster University of Applied Sciences
Stegerwaldstrasse 39 Stegerwaldstrasse 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Maksim Proshin Maksim Proshin
Ericsson Ericsson
 End of changes. 12 change blocks. 
16 lines changed or deleted 490 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/