draft-ietf-tsvwg-rfc4960-errata-07.txt   draft-ietf-tsvwg-rfc4960-errata-08.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: January 17, 2019 Muenster Univ. of Appl. Sciences Expires: April 25, 2019 Muenster Univ. of Appl. Sciences
M. Proshin M. Proshin
Ericsson Ericsson
July 16, 2018 October 22, 2018
RFC 4960 Errata and Issues RFC 4960 Errata and Issues
draft-ietf-tsvwg-rfc4960-errata-07.txt draft-ietf-tsvwg-rfc4960-errata-08.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 document provides deltas to RFC4960 and is organized in a time
ordered way. The issues are listed in the order they were brought ordered way. The issues are listed in the order they were brought
up. Because some text is changed several times the last delta in the up. 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 text 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 January 17, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.3. Registration of New Chunk Types . . . . . . . . . . . . . 6 3.3. Registration of New Chunk Types . . . . . . . . . . . . . 6
3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 7 3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 7
3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 8 3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 8
3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 9 3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 9
3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 10 3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 10
3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 11 3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 11
3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 12 3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 12
3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 19 3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 19
3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 20 3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 20
3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 21 3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 21
3.13. HEARTBEAT ACK and the association error counter . . . . . 21 3.13. HEARTBEAT ACK and the association error counter . . . . . 22
3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 23 3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 23
3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 24 3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 24
3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 24 3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 25
3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 25 3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 26
3.18. Only One Packet after Retransmission Timeout . . . . . . 26 3.18. Only One Packet after Retransmission Timeout . . . . . . 27
3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 27 3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 28
3.20. Zero Window Probing and Unreachable Primary Path . . . . 28 3.20. Zero Window Probing and Unreachable Primary Path . . . . 29
3.21. Normative Language in Section 10 . . . . . . . . . . . . 29 3.21. Normative Language in Section 10 . . . . . . . . . . . . 30
3.22. Increase of partial_bytes_acked in Congestion Avoidance . 33 3.22. Increase of partial_bytes_acked in Congestion Avoidance . 33
3.23. Inconsistency in Notifications Handling . . . . . . . . . 34 3.23. Inconsistency in Notifications Handling . . . . . . . . . 34
3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 38 3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 40
3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 40 3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 42
3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 41 3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 43
3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 43 3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 46
3.28. Window Updates After Receiver Window Opens Up . . . . . . 44 3.28. Window Updates After Receiver Window Opens Up . . . . . . 47
3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 45 3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 48
3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 47 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 50
3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 48 3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 52
3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 49 3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 53
3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 51 3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 55
3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 51 3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 56
3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 52 3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 57
3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 54 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 58
3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 55 3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 60
3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 56 3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 60
3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 57 3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 62
3.40. Updating References Regarding ECN . . . . . . . . . . . . 59 3.40. Updating References Regarding ECN . . . . . . . . . . . . 64
3.41. Host Name Address Parameter Deprecated . . . . . . . . . 60 3.41. Host Name Address Parameter Deprecated . . . . . . . . . 66
3.42. Conflicting Text Regarding the Supported Address Types 3.42. Conflicting Text Regarding the Supported Address Types
Parameter . . . . . . . . . . . . . . . . . . . . . . . . 64 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 70
3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 65 3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 71
3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 67 3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 73
3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 69 3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 75
3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 72 3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 79
3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 82 3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 89
3.48. Handling of SSN Wrap Arounds . . . . . . . . . . . . . . 84 3.48. Handling of SSN Wrap Arounds . . . . . . . . . . . . . . 91
3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 85 3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 92
3.50. Missed Text Removal . . . . . . . . . . . . . . . . . . . 85 3.50. Missed Text Removal . . . . . . . . . . . . . . . . . . . 93
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94
5. Security Considerations . . . . . . . . . . . . . . . . . . . 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 94
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 86 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.1. Normative References . . . . . . . . . . . . . . . . . . 87 7.1. Normative References . . . . . . . . . . . . . . . . . . 95
7.2. Informative References . . . . . . . . . . . . . . . . . 87 7.2. Informative References . . . . . . . . . . . . . . . . . 95
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96
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 publication of this document for [RFC4960] specifying the Stream the publication 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 5, line 28 skipping to change at page 5, line 28
--------- ---------
When the value of this counter exceeds the protocol parameter When the value of this counter exceeds the protocol parameter
'Path.Max.Retrans', the endpoint SHOULD mark the corresponding 'Path.Max.Retrans', the endpoint SHOULD mark the corresponding
destination address as inactive if it is not so marked, and MAY also destination address as inactive if it is not so marked, and MAY also
optionally report to the upper layer the change of reachability of optionally report to the upper layer the change of reachability of
this destination address. After this, the endpoint SHOULD continue this destination address. After this, the endpoint SHOULD continue
HEARTBEAT on this destination address but SHOULD stop increasing the HEARTBEAT on this destination address but SHOULD stop increasing the
counter. counter.
This text has been modified by multiple errata. It is further
updated in Section 3.23.
3.1.3. Solution Description 3.1.3. Solution Description
The intended state change should happen when the threshold is The intended state change should happen when the threshold is
exceeded. exceeded.
3.2. Upper Layer Protocol Shutdown Request Handling 3.2. Upper Layer Protocol Shutdown Request Handling
3.2.1. Description of the Problem 3.2.1. Description of the Problem
Section 9.2 of [RFC4960] describes the handling of received SHUTDOWN Section 9.2 of [RFC4960] describes the handling of received SHUTDOWN
skipping to change at page 6, line 20 skipping to change at page 6, line 20
subsequent SHUTDOWN chunks. subsequent SHUTDOWN chunks.
--------- ---------
New text: (Section 9.2) New text: (Section 9.2)
--------- ---------
Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST
ignore ULP shutdown requests, but MUST continue responding ignore ULP shutdown requests, but MUST continue responding
to SHUTDOWN chunks from its peer. to SHUTDOWN chunks from its peer.
This text is in final form, and is not further updated in this
document.
3.2.3. Solution Description 3.2.3. Solution Description
The text never intended the SCTP endpoint to ignore SHUTDOWN chunks The text never intended the SCTP endpoint to ignore SHUTDOWN chunks
from its peer. If it did, the endpoints could never gracefully from its peer. If it did, the endpoints could never gracefully
terminate associations in some cases. terminate associations in some cases.
3.3. Registration of New Chunk Types 3.3. Registration of New Chunk Types
3.3.1. Description of the Problem 3.3.1. Description of the Problem
skipping to change at page 7, line 20 skipping to change at page 7, line 20
chunk parameter MUST contain the following information: chunk parameter MUST contain the following information:
--------- ---------
New text: (Section 14.1) New text: (Section 14.1)
--------- ---------
The assignment of new chunk type codes is done through an The assignment of new chunk type codes is done through an
IETF Consensus action, as defined in [RFC8126]. Documentation of the IETF Consensus action, as defined in [RFC8126]. Documentation of the
chunk type MUST contain the following information: chunk type MUST contain the following information:
This text has been modified by multiple errata. It is further
updated in Section 3.43.
3.3.3. Solution Description 3.3.3. Solution Description
Refer to chunk types as intended and change reference to [RFC8126]. Refer to chunk types as intended and change reference to [RFC8126].
3.4. Variable Parameters for INIT Chunks 3.4. Variable Parameters for INIT Chunks
3.4.1. Description of the Problem 3.4.1. Description of the Problem
Newlines in wrong places break the layout of the table of variable Newlines in wrong places break the layout of the table of variable
parameters for the INIT chunk in Section 3.3.2 of [RFC4960]. parameters for the INIT chunk in Section 3.3.2 of [RFC4960].
skipping to change at page 8, line 29 skipping to change at page 8, line 29
Variable Parameters Status Type Value Variable Parameters Status Type Value
------------------------------------------------------------- -------------------------------------------------------------
IPv4 Address (Note 1) Optional 5 IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6 IPv6 Address (Note 1) Optional 6
Cookie Preservative Optional 9 Cookie Preservative Optional 9
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11 Host Name Address (Note 3) Optional 11
Supported Address Types (Note 4) Optional 12 Supported Address Types (Note 4) Optional 12
This text is in final form, and is not further updated in this
document.
3.4.3. Solution Description 3.4.3. Solution Description
Fix the formatting of the table. Fix the formatting of the table.
3.5. CRC32c Sample Code on 64-bit Platforms 3.5. CRC32c Sample Code on 64-bit Platforms
3.5.1. Description of the Problem 3.5.1. Description of the Problem
The sample code for computing the CRC32c provided in [RFC4960] The sample code for computing the CRC32c provided in [RFC4960]
assumes that a variable of type unsigned long uses 32 bits. This is assumes that a variable of type unsigned long uses 32 bits. This is
skipping to change at page 9, line 24 skipping to change at page 9, line 24
--------- ---------
New text: (Appendix C) New text: (Appendix C)
--------- ---------
unsigned long unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length) generate_crc32c(unsigned char *buffer, unsigned int length)
{ {
unsigned int i; unsigned int i;
unsigned long crc32 = 0xffffffffL; unsigned long crc32 = 0xffffffffL;
This text has been modified by multiple errata. It is further
updated in Section 3.10 and in Section 3.46.
3.5.3. Solution Description 3.5.3. Solution Description
Use 0xffffffffL instead of ~0L which gives the same value on Use 0xffffffffL instead of ~0L which gives the same value on
platforms using 32 bits or 64 bits for variables of type unsigned platforms using 32 bits or 64 bits for variables of type unsigned
long. long.
3.6. Endpoint Failure Detection 3.6. Endpoint Failure Detection
3.6.1. Description of the Problem 3.6.1. Description of the Problem
skipping to change at page 10, line 28 skipping to change at page 10, line 28
retransmissions to its peer (this includes data retransmissions retransmissions to its peer (this includes data retransmissions
to all the destination transport addresses of the peer if it is to all the destination transport addresses of the peer if it is
multi-homed), including the number of unacknowledged HEARTBEAT multi-homed), including the number of unacknowledged HEARTBEAT
chunks observed on the path which is currently used for data chunks observed on the path which is currently used for data
transfer. Unacknowledged HEARTBEAT chunks observed on paths transfer. Unacknowledged HEARTBEAT chunks observed on paths
different from the path currently used for data transfer SHOULD different from the path currently used for data transfer SHOULD
NOT increment the association error counter, as this could lead NOT increment the association error counter, as this could lead
to association closure even if the path which is currently used for to association closure even if the path which is currently used for
data transfer is available (but idle). data transfer is available (but idle).
This text has been modified by multiple errata. It is further
updated in Section 3.23.
3.6.3. Solution Description 3.6.3. Solution Description
A more refined handling for the association error counter is defined. A more refined handling for the association error counter is defined.
3.7. Data Transmission Rules 3.7. Data Transmission Rules
3.7.1. Description of the Problem 3.7.1. Description of the Problem
When integrating the changes to Section 6.1 A) of [RFC2960] as When integrating the changes to Section 6.1 A) of [RFC2960] as
described in Section 2.15.2 of [RFC4460] some text was duplicated and described in Section 2.15.2 of [RFC4460] some text was duplicated and
skipping to change at page 11, line 29 skipping to change at page 11, line 29
--------- ---------
New text: (Section 6.1 A)) New text: (Section 6.1 A))
--------- ---------
The sender MUST also have an algorithm for sending new DATA chunks The sender MUST also have an algorithm for sending new DATA chunks
to avoid silly window syndrome (SWS) as described in [RFC1122]. to avoid silly window syndrome (SWS) as described in [RFC1122].
The algorithm can be similar to the one described in Section The algorithm can be similar to the one described in Section
4.2.3.4 of [RFC1122]. 4.2.3.4 of [RFC1122].
This text is in final form, and is not further updated in this
document.
3.7.3. Solution Description 3.7.3. Solution Description
Last paragraph of Section 6.1 A) removed as intended in Last paragraph of Section 6.1 A) removed as intended in
Section 2.15.2 of [RFC4460]. Section 2.15.2 of [RFC4460].
3.8. T1-Cookie Timer 3.8. T1-Cookie Timer
3.8.1. Description of the Problem 3.8.1. Description of the Problem
Figure 4 of [RFC4960] illustrates the SCTP association setup. Figure 4 of [RFC4960] illustrates the SCTP association setup.
skipping to change at page 12, line 30 skipping to change at page 12, line 33
COOKIE ECHO [Cookie_Z] ------\ COOKIE ECHO [Cookie_Z] ------\
(Start T1-cookie timer) \ (Start T1-cookie timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state) state)
/---- COOKIE-ACK /---- COOKIE-ACK
/ /
(Cancel T1-cookie timer, <---/ (Cancel T1-cookie timer, <---/
Enter ESTABLISHED state) Enter ESTABLISHED state)
This text has been modified by multiple errata. It is further
updated in Section 3.9.
3.8.3. Solution Description 3.8.3. Solution Description
Change the figure such that the T1-cookie timer is used instead of Change the figure such that the T1-cookie timer is used instead of
the T1-init timer. the T1-init timer.
3.9. Miscellaneous Typos 3.9. Miscellaneous Typos
3.9.1. Description of the Problem 3.9.1. Description of the Problem
While processing [RFC4960] some typos were not caught. While processing [RFC4960] some typos were not caught.
skipping to change at page 13, line 20 skipping to change at page 13, line 23
2*32 - 1 is TSN = 0. 2*32 - 1 is TSN = 0.
--------- ---------
New text: (Section 1.6) New text: (Section 1.6)
--------- ---------
Transmission Sequence Numbers wrap around when they reach 2**32 - 1. Transmission Sequence Numbers wrap around when they reach 2**32 - 1.
That is, the next TSN a DATA chunk MUST use after transmitting TSN = That is, the next TSN a DATA chunk MUST use after transmitting TSN =
2**32 - 1 is TSN = 0. 2**32 - 1 is TSN = 0.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 3.3.10.9) Old text: (Section 3.3.10.9)
--------- ---------
No User Data: This error cause is returned to the originator of a No User Data: This error cause is returned to the originator of a
DATA chunk if a received DATA chunk has no user data. DATA chunk if a received DATA chunk has no user data.
--------- ---------
New text: (Section 3.3.10.9) New text: (Section 3.3.10.9)
--------- ---------
No User Data: This error cause is returned to the originator of a No User Data: This error cause is returned to the originator of a
DATA chunk if a received DATA chunk has no user data. DATA chunk if a received DATA chunk has no user data.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 6.7, Figure 9) Old text: (Section 6.7, Figure 9)
--------- ---------
Endpoint A Endpoint Z {App Endpoint A Endpoint Z {App
sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ---------- sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ----------
-----> (ack delayed) (Start T3-rtx timer) -----> (ack delayed) (Start T3-rtx timer)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
skipping to change at page 15, line 5 skipping to change at page 14, line 41
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack) immediately send ack)
/----- SACK [TSN Ack=6,Block=1, /----- SACK [TSN Ack=6,Block=1,
/ Start=2,End=2] / Start=2,End=2]
<-----/ <-----/
(remove 6 from out-queue, (remove 6 from out-queue,
and mark 7 as "1" missing report) and mark 7 as "1" missing report)
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 6.10) Old text: (Section 6.10)
--------- ---------
An endpoint bundles chunks by simply including multiple chunks in one An endpoint bundles chunks by simply including multiple chunks in one
outbound SCTP packet. The total size of the resultant IP datagram, outbound SCTP packet. The total size of the resultant IP datagram,
including the SCTP packet and IP headers, MUST be less that or equal including the SCTP packet and IP headers, MUST be less that or equal
to the current Path MTU. to the current Path MTU.
--------- ---------
New text: (Section 6.10) New text: (Section 6.10)
--------- ---------
An endpoint bundles chunks by simply including multiple chunks in one An endpoint bundles chunks by simply including multiple chunks in one
outbound SCTP packet. The total size of the resultant IP datagram, outbound SCTP packet. The total size of the resultant IP datagram,
including the SCTP packet and IP headers, MUST be less than or equal including the SCTP packet and IP headers, MUST be less than or equal
to the current PMTU. to the current PMTU.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1 O))
--------- ---------
o Receive Unacknowledged Message o Receive Unacknowledged Message
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
size, [,stream id] [, stream sequence number] [,partial size, [,stream id] [, stream sequence number] [,partial
flag] [,payload protocol-id]) flag] [,payload protocol-id])
--------- ---------
New text: (Section 10.1) New text: (Section 10.1 O))
--------- ---------
O) Receive Unacknowledged Message O) Receive Unacknowledged Message
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
size [,stream id] [,stream sequence number] [,partial size [,stream id] [,stream sequence number] [,partial
flag] [,payload protocol-id]) flag] [,payload protocol-id])
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1 M))
--------- ---------
M) Set Protocol Parameters M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id, Format: SETPROTOCOLPARAMETERS(association id,
[,destination transport address,] [,destination transport address,]
protocol parameter list) protocol parameter list)
--------- ---------
New text: (Section 10.1) New text: (Section 10.1 M))
--------- ---------
M) Set Protocol Parameters M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id, Format: SETPROTOCOLPARAMETERS(association id,
[destination transport address,] [destination transport address,]
protocol parameter list) protocol parameter list)
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Appendix C) Old text: (Appendix C)
--------- ---------
ICMP2) An implementation MAY ignore all ICMPv6 messages where the ICMP2) An implementation MAY ignore all ICMPv6 messages where the
type field is not "Destination Unreachable", "Parameter type field is not "Destination Unreachable", "Parameter
Problem",, or "Packet Too Big". Problem",, or "Packet Too Big".
--------- ---------
New text: (Appendix C) New text: (Appendix C)
--------- ---------
ICMP2) An implementation MAY ignore all ICMPv6 messages where the ICMP2) An implementation MAY ignore all ICMPv6 messages where the
type field is not "Destination Unreachable", "Parameter type field is not "Destination Unreachable", "Parameter
Problem", or "Packet Too Big". Problem", or "Packet Too Big".
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Appendix C) Old text: (Appendix C)
--------- ---------
ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4
"Fragmentation Needed", an implementation MAY process this "Fragmentation Needed", an implementation MAY process this
information as defined for PATH MTU discovery. information as defined for PATH MTU discovery.
--------- ---------
New text: (Appendix C) New text: (Appendix C)
--------- ---------
ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4
"Fragmentation Needed", an implementation MAY process this "Fragmentation Needed", an implementation MAY process this
information as defined for PMTU discovery. information as defined for PMTU discovery.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 5.4) Old text: (Section 5.4)
--------- ---------
2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address
is the one to which the INIT-ACK was sent. is the one to which the INIT-ACK was sent.
--------- ---------
New text: (Section 5.4) New text: (Section 5.4)
--------- ---------
2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address
is the one to which the INIT ACK was sent. is the one to which the INIT ACK was sent.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 5.1.6, Figure 4) Old text: (Section 5.1.6, Figure 4)
--------- ---------
COOKIE ECHO [Cookie_Z] ------\ COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \ (Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state) state)
/---- COOKIE-ACK /---- COOKIE-ACK
/ /
skipping to change at page 18, line 31 skipping to change at page 18, line 31
COOKIE ECHO [Cookie_Z] ------\ COOKIE ECHO [Cookie_Z] ------\
(Start T1-cookie timer) \ (Start T1-cookie timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state) state)
/---- COOKIE ACK /---- COOKIE ACK
/ /
(Cancel T1-cookie timer, <---/ (Cancel T1-cookie timer, <---/
Enter ESTABLISHED state) Enter ESTABLISHED state)
This text has been modified by multiple errata. It includes
modifications from Section 3.8. It is in final form, and is not
further updated in this document.
--------- ---------
Old text: (Section 5.2.5) Old text: (Section 5.2.5)
--------- ---------
5.2.5. Handle Duplicate COOKIE-ACK. 5.2.5. Handle Duplicate COOKIE-ACK.
--------- ---------
New text: (Section 5.2.5) New text: (Section 5.2.5)
--------- ---------
5.2.5. Handle Duplicate COOKIE ACK. 5.2.5. Handle Duplicate COOKIE ACK.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 8.3) Old text: (Section 8.3)
--------- ---------
By default, an SCTP endpoint SHOULD monitor the reachability of the By default, an SCTP endpoint SHOULD 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 SHUTDOWN ESTABLISHED state and is discontinued after sending either SHUTDOWN
or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a
skipping to change at page 19, line 34 skipping to change at page 19, line 34
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 SHUTDOWN ESTABLISHED state and is discontinued after sending either SHUTDOWN
or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a
HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state
(INIT sender) or the ESTABLISHED state (INIT receiver), up until (INIT sender) or the ESTABLISHED state (INIT receiver), up until
reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-
ACK-SENT state (SHUTDOWN receiver). ACK-SENT state (SHUTDOWN receiver).
This text is in final form, and is not further updated in this
document.
3.9.3. Solution Description 3.9.3. Solution Description
Typos fixed. Typos fixed.
3.10. CRC32c Sample Code 3.10. CRC32c Sample Code
3.10.1. Description of the Problem 3.10.1. Description of the Problem
The CRC32c computation is described in Appendix B of [RFC4960]. The CRC32c computation is described in Appendix B of [RFC4960].
However, the corresponding sample code and its explanation appears at However, the corresponding sample code and its explanation appears at
skipping to change at page 20, line 10 skipping to change at page 20, line 15
3.10.2. Text Changes to the Document 3.10.2. Text Changes to the Document
Move all of Appendix C starting with the following sentence to the Move all of Appendix C starting with the following sentence to the
end of Appendix B. end of Appendix B.
The following non-normative sample code is taken from an open-source The following non-normative sample code is taken from an open-source
CRC generator [WILLIAMS93], using the "mirroring" technique and CRC generator [WILLIAMS93], using the "mirroring" technique and
yielding a lookup table for SCTP CRC32c with 256 entries, each 32 yielding a lookup table for SCTP CRC32c with 256 entries, each 32
bits wide. bits wide.
This text has been modified by multiple errata. It includes
modifications from Section 3.5. It is further updated in
Section 3.46.
3.10.3. Solution Description 3.10.3. Solution Description
Text moved to the appropriate location. Text moved to the appropriate location.
3.11. partial_bytes_acked after T3-rtx Expiration 3.11. partial_bytes_acked after T3-rtx Expiration
3.11.1. Description of the Problem 3.11.1. Description of the Problem
Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked
should be reset to 0 after packet loss detection from SACK but the should be reset to 0 after packet loss detection from SACK but the
skipping to change at page 20, line 44 skipping to change at page 21, line 4
--------- ---------
New text: (Section 7.2.3) New text: (Section 7.2.3)
--------- ---------
When the T3-rtx timer expires on an address, SCTP SHOULD perform slow When the T3-rtx timer expires on an address, SCTP SHOULD perform slow
start by: start by:
ssthresh = max(cwnd/2, 4*MTU) ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU cwnd = 1*MTU
partial_bytes_acked = 0 partial_bytes_acked = 0
This text is in final form, and is not further updated in this
document.
3.11.3. Solution Description 3.11.3. Solution Description
Specify that partial_bytes_acked should be reset to 0 after T3-rtx Specify that partial_bytes_acked should be reset to 0 after T3-rtx
timer expiration. timer expiration.
3.12. Order of Adjustments of partial_bytes_acked and cwnd 3.12. Order of Adjustments of partial_bytes_acked and cwnd
3.12.1. Description of the Problem 3.12.1. Description of the Problem
skipping to change at page 21, line 35 skipping to change at page 21, line 42
--------- ---------
New text: (Section 7.2.2) New text: (Section 7.2.2)
--------- ---------
o When partial_bytes_acked is equal to or greater than cwnd and o When partial_bytes_acked is equal to or greater than cwnd and
before the arrival of the SACK the sender had cwnd or more bytes before the arrival of the SACK the sender had cwnd or more bytes
of data outstanding (i.e., before arrival of the SACK, flightsize of data outstanding (i.e., before arrival of the SACK, flightsize
was greater than or equal to cwnd), partial_bytes_acked is reset was greater than or equal to cwnd), partial_bytes_acked is reset
to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU. to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU.
This text has been modified by multiple errata. It is further
updated in Section 3.26.
3.12.3. Solution Description 3.12.3. Solution Description
The new text defines the exact order of adjustments of The new text defines the exact order of adjustments of
partial_bytes_acked and cwnd in the congestion avoidance phase. partial_bytes_acked and cwnd in the congestion avoidance phase.
3.13. HEARTBEAT ACK and the association error counter 3.13. HEARTBEAT ACK and the association error counter
3.13.1. Description of the Problem 3.13.1. Description of the Problem
Section 8.1 and Section 8.3 of [RFC4960] prescribe that the receiver Section 8.1 and Section 8.3 of [RFC4960] prescribe that the receiver
skipping to change at page 22, line 27 skipping to change at page 22, line 39
--------- ---------
The counter MUST be reset each time a DATA chunk sent to that peer The counter MUST be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK). When a endpoint is acknowledged (by the reception of a SACK). When a
HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD
also be reset. The receiver of the HEARTBEAT ACK MAY choose not to also be reset. The receiver of the HEARTBEAT ACK MAY choose not to
clear the counter if there is outstanding data on the association. clear the counter if there is outstanding data on the association.
This allows for handling the possible difference in reachability This allows for handling the possible difference in reachability
based on DATA chunks and HEARTBEAT chunks. based on DATA chunks and HEARTBEAT chunks.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 8.3) Old text: (Section 8.3)
--------- ---------
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
should clear the error counter of the destination transport address should clear the error counter of the destination transport address
to which the HEARTBEAT was sent, and mark the destination transport to which the HEARTBEAT was sent, and mark the destination transport
address as active if it is not so marked. The endpoint may address as active if it is not so marked. The endpoint may
optionally report to the upper layer when an inactive destination optionally report to the upper layer when an inactive destination
address is marked as active due to the reception of the latest address is marked as active due to the reception of the latest
skipping to change at page 23, line 5 skipping to change at page 23, line 31
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
MUST clear the error counter of the destination transport address MUST clear the error counter of the destination transport address
to which the HEARTBEAT was sent, and mark the destination transport to which the HEARTBEAT was sent, and mark the destination transport
address as active if it is not so marked. The endpoint MAY address as active if it is not so marked. The endpoint MAY
optionally report to the upper layer when an inactive destination optionally report to the upper layer when an inactive destination
address is marked as active due to the reception of the latest address is marked as active due to the reception of the latest
HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear
the association overall error counter (as defined in Section 8.1). the association overall error counter (as defined in Section 8.1).
This text has been modified by multiple errata. It is further
updated in Section 3.23.
3.13.3. Solution Description 3.13.3. Solution Description
The new text provides a possibility to not reset the association The new text provides a possibility to not reset the association
overall error counter when a HEARTBEAT ACK is received if there are overall error counter when a HEARTBEAT ACK is received if there are
valid reasons for it. valid reasons for it.
3.14. Path for Fast Retransmission 3.14. Path for Fast Retransmission
3.14.1. Description of the Problem 3.14.1. Description of the Problem
skipping to change at page 23, line 45 skipping to change at page 24, line 28
retransmit a chunk that timed out to an active destination transport retransmit a chunk that timed out to an active destination transport
address that is different from the last destination address to which address that is different from the last destination address to which
the DATA chunk was sent. the DATA chunk was sent.
When its peer is multi-homed, an endpoint SHOULD send fast When its peer is multi-homed, an endpoint SHOULD send fast
retransmissions to the same destination transport address where the retransmissions to the same destination transport address where the
original data was sent to. If the primary path has been changed and the original data was sent to. If the primary path has been changed and the
original data was sent to the old primary path before the fast original data was sent to the old primary path before the fast
retransmit, the implementation MAY send it to the new primary path. retransmit, the implementation MAY send it to the new primary path.
This text is in final form, and is not further updated in this
document.
3.14.3. Solution Description 3.14.3. Solution Description
The new text clarifies where to send fast retransmissions. The new text clarifies where to send fast retransmissions.
3.15. Transmittal in Fast Recovery 3.15. Transmittal in Fast Recovery
3.15.1. Description of the Problem 3.15.1. Description of the Problem
The Fast Retransmit on Gap Reports algorithm intends that only the The Fast Retransmit on Gap Reports algorithm intends that only the
very first packet may be sent regardless of cwnd in the Fast Recovery very first packet may be sent regardless of cwnd in the Fast Recovery
skipping to change at page 24, line 42 skipping to change at page 25, line 30
3) If not in Fast Recovery, determine how many of the earliest 3) If not in Fast Recovery, determine how many of the earliest
(i.e., lowest TSN) DATA chunks marked for retransmission will fit (i.e., lowest TSN) DATA chunks marked for retransmission will fit
into a single packet, subject to constraint of the PMTU of into a single packet, subject to constraint of the PMTU of
the destination transport address to which the packet is being the destination transport address to which the packet is being
sent. Call this value K. Retransmit those K DATA chunks in a sent. Call this value K. Retransmit those K DATA chunks in a
single packet. When a Fast Retransmit is being performed, the single packet. When a Fast Retransmit is being performed, the
sender SHOULD ignore the value of cwnd and SHOULD NOT delay sender SHOULD ignore the value of cwnd and SHOULD NOT delay
retransmission for this single packet. retransmission for this single packet.
This text is in final form, and is not further updated in this
document.
3.15.3. Solution Description 3.15.3. Solution Description
The new text explicitly specifies to send only the first packet in The new text explicitly specifies to send only the first packet in
the Fast Recovery phase disregarding cwnd limitations. the Fast Recovery phase disregarding cwnd limitations.
3.16. Initial Value of ssthresh 3.16. Initial Value of ssthresh
3.16.1. Description of the Problem 3.16.1. Description of the Problem
The initial value of ssthresh should be set arbitrarily high. Using The initial value of ssthresh should be set arbitrarily high. Using
the advertised receiver window of the peer is inappropriate if the the advertised receiver window of the peer is inappropriate if the
peer increases its window after the handshake. Furthermore, use a peer increases its window after the handshake. Furthermore, use a
higher requirements level, since not following the advice may result higher requirements level, since not following the advice may result
in performance problems. in performance problems.
3.16.2. Text Changes to the Document 3.16.2. Text Changes to the Document
skipping to change at page 25, line 29 skipping to change at page 26, line 22
example, implementations MAY use the size of the receiver example, implementations MAY use the size of the receiver
advertised window). advertised window).
--------- ---------
New text: (Section 7.2.1) New text: (Section 7.2.1)
--------- ---------
o The initial value of ssthresh SHOULD be arbitrarily high (e.g., o The initial value of ssthresh SHOULD be arbitrarily high (e.g.,
the size of the largest possible advertised window). the size of the largest possible advertised window).
This text is in final form, and is not further updated in this
document.
3.16.3. Solution Description 3.16.3. Solution Description
Use the same value as suggested in [RFC5681], Section 3.1, as an Use the same value as suggested in [RFC5681], Section 3.1, as an
appropriate initial value. Furthermore, use the same requirements appropriate initial value. Furthermore, use the same requirements
level. level.
3.17. Automatically Confirmed Addresses 3.17. Automatically Confirmed Addresses
3.17.1. Description of the Problem 3.17.1. Description of the Problem
skipping to change at page 26, line 19 skipping to change at page 27, line 19
is automatically considered to be CONFIRMED. is automatically considered to be CONFIRMED.
--------- ---------
New text: (Section 5.4) New text: (Section 5.4)
--------- ---------
1) Any addresses passed to the sender of the INIT by its upper 1) Any addresses passed to the sender of the INIT by its upper
layer in the request to initialize an association are layer in the request to initialize an association are
automatically considered to be CONFIRMED. automatically considered to be CONFIRMED.
This text is in final form, and is not further updated in this
document.
3.17.3. Solution Description 3.17.3. Solution Description
The new text clarifies that only addresses provided by the upper The new text clarifies that only addresses provided by the upper
layer in the request to initialize an association are automatically layer in the request to initialize an association are automatically
confirmed. confirmed.
3.18. Only One Packet after Retransmission Timeout 3.18. Only One Packet after Retransmission Timeout
3.18.1. Description of the Problem 3.18.1. Description of the Problem
skipping to change at page 27, line 19 skipping to change at page 28, line 19
than 1*MTU. than 1*MTU.
--------- ---------
New text: (Section 7.2.1) New text: (Section 7.2.1)
--------- ---------
o The initial cwnd after a retransmission timeout MUST be no more o The initial cwnd after a retransmission timeout MUST be no more
than 1*MTU and only one packet is allowed to be in flight than 1*MTU and only one packet is allowed to be in flight
until successful acknowledgement. until successful acknowledgement.
This text is in final form, and is not further updated in this
document.
3.18.3. Solution Description 3.18.3. Solution Description
The new text clearly specifies that only one packet is allowed to be The new text clearly specifies that only one packet is allowed to be
sent after T3-rtx timer expiration until successful acknowledgement. sent after T3-rtx timer expiration until successful acknowledgement.
3.19. INIT ACK Path for INIT in COOKIE-WAIT State 3.19. INIT ACK Path for INIT in COOKIE-WAIT State
3.19.1. Description of the Problem 3.19.1. Description of the Problem
In case of an INIT received in the COOKIE-WAIT state [RFC4960] In case of an INIT received in the COOKIE-WAIT state [RFC4960]
skipping to change at page 28, line 32 skipping to change at page 29, line 32
1) The INIT ACK MUST only be sent to an address passed by the upper 1) The INIT ACK MUST only be sent to an address passed by the upper
layer in the request to initialize the association. layer in the request to initialize the association.
2) The INIT ACK MUST only be sent to an address reported in the 2) The INIT ACK MUST only be sent to an address reported in the
incoming INIT. incoming INIT.
3) The INIT ACK SHOULD be sent to the source address of the 3) The INIT ACK SHOULD be sent to the source address of the
received INIT. received INIT.
This text is in final form, and is not further updated in this
document.
3.19.3. Solution Description 3.19.3. Solution Description
The new text requires sending INIT ACK to a destination address that The new text requires sending INIT ACK to a destination address that
is passed by the upper layer and reported in the incoming INIT. If is passed by the upper layer and reported in the incoming INIT. If
the source address of the INIT meets these conditions, sending the the source address of the INIT meets these conditions, sending the
INIT ACK to the source address of the INIT is the preferred behavior. INIT ACK to the source address of the INIT is the preferred behavior.
3.20. Zero Window Probing and Unreachable Primary Path 3.20. Zero Window Probing and Unreachable Primary Path
3.20.1. Description of the Problem 3.20.1. Description of the Problem
skipping to change at page 29, line 29 skipping to change at page 30, line 31
New text: (Section 6.1) New text: (Section 6.1)
--------- ---------
If the sender continues to receive SACKs from the peer If the sender continues to receive SACKs from the peer
while doing zero window probing, the unacknowledged window probes while doing zero window probing, the unacknowledged window probes
SHOULD NOT increment the error counter for the association or any SHOULD NOT increment the error counter for the association or any
destination transport address. This is because the receiver could destination transport address. This is because the receiver could
keep its window closed for an indefinite time. Section 6.2 describes keep its window closed for an indefinite time. Section 6.2 describes
the receiver behavior when it advertises a zero window. the receiver behavior when it advertises a zero window.
This text is in final form, and is not further updated in this
document.
3.20.3. Solution Description 3.20.3. Solution Description
The new text clarifies that if the receiver continues to send SACKs, The new text clarifies that if the receiver continues to send SACKs,
the sender of probes should not increment the error counter of the the sender of probes should not increment the error counter of the
association and the destination address even if the SACKs do not association and the destination address even if the SACKs do not
acknowledge the probes. acknowledge the probes.
3.21. Normative Language in Section 10 3.21. Normative Language in Section 10
3.21.1. Description of the Problem 3.21.1. Description of the Problem
Section 10 of [RFC4960] is informative and, therefore, normative Section 10 of [RFC4960] is informative and, therefore, normative
language such as MUST and MAY cannot be used there. However, there language such as MUST and MAY cannot be used there. However, there
are several places in Section 10 where MUST and MAY are used. are several places in Section 10 where MUST and MAY are used.
3.21.2. Text Changes to the Document 3.21.2. Text Changes to the Document
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1 E))
--------- ---------
E) Send
Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address]
[,unordered flag] [,no-bundle flag] [,payload protocol-id] )
-> result
...
o no-bundle flag - instructs SCTP not to bundle this user data with
other outbound DATA chunks. SCTP MAY still bundle even when this
flag is present, when faced with network congestion.
---------
New text: (Section 10.1)
---------
E) Send o no-bundle flag - instructs SCTP not to bundle this user data with
other outbound DATA chunks. SCTP MAY still bundle even when this
flag is present, when faced with network congestion.
Format: SEND(association id, buffer address, byte count [,context] ---------
[,stream id] [,life time] [,destination transport address] New text: (Section 10.1 E))
[,unordered flag] [,no-bundle flag] [,payload protocol-id] ) ---------
-> result
... o no-bundle flag - instructs SCTP not to bundle this user data with
other outbound DATA chunks. SCTP may still bundle even when this
flag is present, when faced with network congestion.
o no-bundle flag - instructs SCTP not to bundle this user data with This text is in final form, and is not further updated in this
other outbound DATA chunks. SCTP may still bundle even when this document.
flag is present, when faced with network congestion.
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1 G))
--------- ---------
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]
...
o Stream Sequence Number - the Stream Sequence Number assigned by o Stream Sequence Number - the Stream Sequence Number assigned by
the sending SCTP peer. the sending SCTP peer.
o partial flag - if this returned flag is set to 1, then this o partial flag - if this returned flag is set to 1, then this
Receive contains a partial delivery of the whole message. When Receive contains a partial delivery of the whole message. When
this flag is set, the stream id and Stream Sequence Number MUST this flag is set, the stream id and Stream Sequence Number MUST
accompany this receive. When this flag is set to 0, it indicates accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence that no more deliveries will be received for this Stream Sequence
Number. Number.
--------- ---------
New text: (Section 10.1) New text: (Section 10.1 G))
--------- ---------
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]
...
o stream sequence number - the Stream Sequence Number assigned by o stream sequence number - the Stream Sequence Number assigned by
the sending SCTP peer. the sending SCTP peer.
o partial flag - if this returned flag is set to 1, then this o partial flag - if this returned flag is set to 1, then this
primitive contains a partial delivery of the whole message. When primitive contains a partial delivery of the whole message. When
this flag is set, the stream id and stream sequence number must this flag is set, the stream id and stream sequence number must
accompany this primitive. When this flag is set to 0, it indicates accompany this primitive. When this flag is set to 0, it indicates
that no more deliveries will be received for this stream sequence that no more deliveries will be received for this stream sequence
number. number.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1 N))
--------- ---------
N) Receive Unsent Message
Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer
size [,stream id] [, stream sequence number] [,partial
flag] [,payload protocol-id])
...
o Stream Sequence Number - this value is returned indicating the o Stream Sequence Number - this value is returned indicating the
Stream Sequence Number that was associated with the message. Stream Sequence Number that was associated with the message.
o partial flag - if this returned flag is set to 1, then this o partial flag - if this returned flag is set to 1, then this
message is a partial delivery of the whole message. When this message is a partial delivery of the whole message. When this
flag is set, the stream id and Stream Sequence Number MUST flag is set, the stream id and Stream Sequence Number MUST
accompany this receive. When this flag is set to 0, it indicates accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence that no more deliveries will be received for this Stream Sequence
Number. Number.
--------- ---------
New text: (Section 10.1) New text: (Section 10.1 N))
--------- ---------
N) Receive Unsent Message
Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer
size [,stream id] [, stream sequence number] [,partial
flag] [,payload protocol-id])
...
o stream sequence number - this value is returned indicating the o stream sequence number - this value is returned indicating the
Stream Sequence Number that was associated with the message. Stream Sequence Number that was associated with the message.
o partial flag - if this returned flag is set to 1, then this o partial flag - if this returned flag is set to 1, then this
message is a partial delivery of the whole message. When this message is a partial delivery of the whole message. When this
flag is set, the stream id and stream sequence number must flag is set, the stream id and stream sequence number must
accompany this primitive. When this flag is set to 0, it indicates accompany this primitive. When this flag is set to 0, it indicates
that no more deliveries will be received for this stream sequence that no more deliveries will be received for this stream sequence
number. number.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1 O))
--------- ---------
O) Receive Unacknowledged Message
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
size [,stream id] [,stream sequence number] [,partial
flag] [,payload protocol-id])
...
o Stream Sequence Number - this value is returned indicating the o Stream Sequence Number - this value is returned indicating the
Stream Sequence Number that was associated with the message. Stream Sequence Number that was associated with the message.
o partial flag - if this returned flag is set to 1, then this o partial flag - if this returned flag is set to 1, then this
message is a partial delivery of the whole message. When this message is a partial delivery of the whole message. When this
flag is set, the stream id and Stream Sequence Number MUST flag is set, the stream id and Stream Sequence Number MUST
accompany this receive. When this flag is set to 0, it indicates accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this Stream Sequence that no more deliveries will be received for this Stream Sequence
Number. Number.
--------- ---------
New text: (Section 10.1) New text: (Section 10.1 O))
--------- ---------
O) Receive Unacknowledged Message
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
size [,stream id] [,stream sequence number] [,partial
flag] [,payload protocol-id])
...
o stream sequence number - this value is returned indicating the o stream sequence number - this value is returned indicating the
Stream Sequence Number that was associated with the message. Stream Sequence Number that was associated with the message.
o partial flag - if this returned flag is set to 1, then this o partial flag - if this returned flag is set to 1, then this
message is a partial delivery of the whole message. When this message is a partial delivery of the whole message. When this
flag is set, the stream id and stream sequence number must flag is set, the stream id and stream sequence number must
accompany this primitive. When this flag is set to 0, it indicates accompany this primitive. When this flag is set to 0, it indicates
that no more deliveries will be received for this stream sequence that no more deliveries will be received for this stream sequence
number. number.
This text is in final form, and is not further updated in this
document.
3.21.3. Solution Description 3.21.3. Solution Description
The normative language is removed from Section 10. In addition, the The normative language is removed from Section 10. In addition, the
consistency of the text has been improved. consistency of the text has been improved.
3.22. Increase of partial_bytes_acked in Congestion Avoidance 3.22. Increase of partial_bytes_acked in Congestion Avoidance
3.22.1. Description of the Problem 3.22.1. Description of the Problem
Two issues have been discovered with the partial_bytes_acked handling Two issues have been discovered with the partial_bytes_acked handling
skipping to change at page 34, line 24 skipping to change at page 34, line 31
--------- ---------
New text: (Section 7.2.2) New text: (Section 7.2.2)
--------- ---------
o Whenever cwnd is greater than ssthresh, upon each SACK arrival, o Whenever cwnd is greater than ssthresh, upon each SACK arrival,
increase partial_bytes_acked by the total number of bytes of all increase partial_bytes_acked by the total number of bytes of all
new chunks acknowledged in that SACK including chunks acknowledged new chunks acknowledged in that SACK including chunks acknowledged
by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number
of bytes of duplicated chunks reported in Duplicate TSNs. of bytes of duplicated chunks reported in Duplicate TSNs.
This text has been modified by multiple errata. It is further
updated in Section 3.26.
3.22.3. Solution Description 3.22.3. Solution Description
Now partial_bytes_acked is increased by TSNs reported as duplicated Now partial_bytes_acked is increased by TSNs reported as duplicated
as well as TSNs newly acknowledged in Gap Ack Blocks even if the as well as TSNs newly acknowledged in Gap Ack Blocks even if the
Cumulative TSN Ack Point is not advanced. Cumulative TSN Ack Point is not advanced.
3.23. Inconsistency in Notifications Handling 3.23. Inconsistency in Notifications Handling
3.23.1. Description of the Problem 3.23.1. Description of the Problem
skipping to change at page 34, line 47 skipping to change at page 35, line 9
inactive due to an unacknowledged DATA chunk or HEARTBEAT chunk, SCTP inactive due to an unacknowledged DATA chunk or HEARTBEAT chunk, SCTP
SHOULD send a notification to the upper layer while Section 8.3 of SHOULD send a notification to the upper layer while Section 8.3 of
[RFC4960] says that when a destination address becomes inactive due [RFC4960] says that when a destination address becomes inactive due
to an unacknowledged HEARTBEAT chunk, SCTP may send a notification to to an unacknowledged HEARTBEAT chunk, SCTP may send a notification to
the upper layer. the upper layer.
This makes the text inconsistent. This makes the text inconsistent.
3.23.2. Text Changes to the Document 3.23.2. Text Changes to the Document
The following change is based on the change described in Section 3.6.
--------- ---------
Old text: (Section 8.1) Old text: (Section 8.1)
--------- ---------
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 (this includes data retransmissions retransmissions to its peer (this includes retransmissions to all the
to all the destination transport addresses of the peer if it is destination transport addresses of the peer if it is multi-homed),
multi-homed), including the number of unacknowledged HEARTBEAT including unacknowledged HEARTBEAT chunks.
chunks observed on the path which currently is used for data
transfer. Unacknowledged HEARTBEAT chunks observed on paths
different from the path currently used for data transfer shall
not increment the association error counter, as this could lead
to association closure even if the path which currently is used for
data transfer is available (but idle). If the value of this
counter exceeds the limit indicated in the protocol parameter
'Association.Max.Retrans', the endpoint shall consider the peer
endpoint unreachable and shall stop transmitting any more data to it
(and thus the association enters the CLOSED state). In addition, the
endpoint MAY report the failure to the upper layer and optionally
report back all outstanding user data remaining in its outbound
queue. The association is automatically closed when the peer
endpoint becomes unreachable.
--------- ---------
New text: (Section 8.1) New text: (Section 8.1)
--------- ---------
An endpoint SHOULD keep a counter on the total number of consecutive An endpoint SHOULD keep a counter on the total number of consecutive
retransmissions to its peer (this includes data retransmissions retransmissions to its peer (this includes data retransmissions
to all the destination transport addresses of the peer if it is to all the destination transport addresses of the peer if it is
multi-homed), including the number of unacknowledged HEARTBEAT multi-homed), including the number of unacknowledged HEARTBEAT
chunks observed on the path which currently is used for data chunks observed on the path which currently is used for data
skipping to change at page 35, line 51 skipping to change at page 35, line 41
data transfer is available (but idle). If the value of this data transfer is available (but idle). If the value of this
counter exceeds the limit indicated in the protocol parameter counter exceeds the limit indicated in the protocol parameter
'Association.Max.Retrans', the endpoint SHOULD consider the peer 'Association.Max.Retrans', the endpoint SHOULD 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, the (and thus the association enters the CLOSED state). In addition, the
endpoint SHOULD report the failure to the upper layer and optionally endpoint SHOULD report the failure to the upper layer and optionally
report back all outstanding user data remaining in its outbound report back all outstanding user data remaining in its outbound
queue. The association is automatically closed when the peer queue. The association is automatically closed when the peer
endpoint becomes unreachable. endpoint becomes unreachable.
The following changes are based on [RFC4960]. This text has been modified by multiple errata. It includes
modifications from Section 3.6. It is in final form, and is not
further updated in this document.
--------- ---------
Old text: (Section 8.2) Old text: (Section 8.2)
--------- ---------
When an outstanding TSN is acknowledged or a HEARTBEAT sent to that When an outstanding TSN is acknowledged or a HEARTBEAT sent to that
address is acknowledged with a HEARTBEAT ACK, the endpoint shall address is acknowledged with a HEARTBEAT ACK, the endpoint shall
clear the error counter of the destination transport address to which clear the error counter of the destination transport address to which
the DATA chunk was last sent (or HEARTBEAT was sent). When the peer the DATA chunk was last sent (or HEARTBEAT was sent). When the peer
endpoint is multi-homed and the last chunk sent to it was a endpoint is multi-homed and the last chunk sent to it was a
skipping to change at page 36, line 39 skipping to change at page 36, line 39
also report to the upper layer when an inactive destination address also report to the upper layer when an inactive destination address
is marked as active. When the peer endpoint is multi-homed and the is marked as active. When the peer endpoint is multi-homed and the
last chunk sent to it was a retransmission to an alternate address, last chunk sent to it was a retransmission to an alternate address,
there exists an ambiguity as to whether or not the acknowledgement there exists an ambiguity as to whether or not the acknowledgement
could be credited to the address of the last chunk sent. However, could be credited to the address of the last chunk sent. However,
this ambiguity does not seem to bear any significant consequence to this ambiguity does not seem to bear any significant consequence to
SCTP behavior. If this ambiguity is undesirable, the transmitter MAY SCTP behavior. If this ambiguity is undesirable, the transmitter MAY
choose not to clear the error counter if the last chunk sent was a choose not to clear the error counter if the last chunk sent was a
retransmission. retransmission.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 8.3) Old text: (Section 8.3)
--------- ---------
When the value of this counter reaches the protocol parameter When the value of this counter reaches the protocol parameter
'Path.Max.Retrans', the endpoint should mark the corresponding 'Path.Max.Retrans', the endpoint should mark the corresponding
destination address as inactive if it is not so marked, and may also destination address as inactive if it is not so marked, and may also
optionally report to the upper layer the change of reachability of optionally report to the upper layer the change of reachability of
this destination address. After this, the endpoint should continue this destination address. After this, the endpoint should continue
HEARTBEAT on this destination address but should stop increasing the HEARTBEAT on this destination address but should stop increasing the
skipping to change at page 37, line 14 skipping to change at page 37, line 29
--------- ---------
When the value of this counter exceeds the protocol parameter When the value of this counter exceeds the protocol parameter
'Path.Max.Retrans', the endpoint SHOULD mark the corresponding 'Path.Max.Retrans', the endpoint SHOULD mark the corresponding
destination address as inactive if it is not so marked, and SHOULD destination address as inactive if it is not so marked, and SHOULD
also report to the upper layer the change of reachability of this also report to the upper layer the change of reachability of this
destination address. After this, the endpoint SHOULD continue destination address. After this, the endpoint SHOULD continue
HEARTBEAT on this destination address but SHOULD stop increasing the HEARTBEAT on this destination address but SHOULD stop increasing the
counter. counter.
This text has been modified by multiple errata. It includes
modifications from Section 3.1. It is in final form, and is not
further updated in this document.
--------- ---------
Old text: (Section 8.3) Old text: (Section 8.3)
--------- ---------
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
should clear the error counter of the destination transport address should clear the error counter of the destination transport address
to which the HEARTBEAT was sent, and mark the destination transport to which the HEARTBEAT was sent, and mark the destination transport
address as active if it is not so marked. The endpoint may address as active if it is not so marked. The endpoint may
optionally report to the upper layer when an inactive destination optionally report to the upper layer when an inactive destination
address is marked as active due to the reception of the latest address is marked as active due to the reception of the latest
skipping to change at page 37, line 40 skipping to change at page 38, line 31
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT
SHOULD clear the error counter of the destination transport address SHOULD clear the error counter of the destination transport address
to which the HEARTBEAT was sent, and mark the destination transport to which the HEARTBEAT was sent, and mark the destination transport
address as active if it is not so marked. The endpoint SHOULD address as active if it is not so marked. The endpoint SHOULD
report to the upper layer when an inactive destination address report to the upper layer when an inactive destination address
is marked as active due to the reception of the latest is marked as active due to the reception of the latest
HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear
the association overall error counter (as defined in Section 8.1). the association overall error counter (as defined in Section 8.1).
This text has been modified by multiple errata. It includes
modifications from Section 3.13. It is in final form, and is not
further updated in this document.
--------- ---------
Old text: (Section 9.2) Old text: (Section 9.2)
--------- ---------
An endpoint should limit the number of retransmissions of the An endpoint should limit the number of retransmissions of the
SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'.
If this threshold is exceeded, the endpoint should destroy the TCB If this threshold is exceeded, the endpoint should destroy the TCB
and MUST report the peer endpoint unreachable to the upper layer (and and MUST report the peer endpoint unreachable to the upper layer (and
thus the association enters the CLOSED state). thus the association enters the CLOSED state).
--------- ---------
New text: (Section 9.2) New text: (Section 9.2)
--------- ---------
An endpoint SHOULD limit the number of retransmissions of the An endpoint SHOULD limit the number of retransmissions of the
SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'.
If this threshold is exceeded, the endpoint SHOULD destroy the TCB If this threshold is exceeded, the endpoint SHOULD destroy the TCB
and SHOULD report the peer endpoint unreachable to the upper layer and SHOULD report the peer endpoint unreachable to the upper layer
(and thus the association enters the CLOSED state). (and thus the association enters the CLOSED state).
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 9.2) Old text: (Section 9.2)
--------- ---------
The sender of the SHUTDOWN ACK should limit the number of The sender of the SHUTDOWN ACK should limit the number of
retransmissions of the SHUTDOWN ACK chunk to the protocol parameter retransmissions of the SHUTDOWN ACK chunk to the protocol parameter
'Association.Max.Retrans'. If this threshold is exceeded, the 'Association.Max.Retrans'. If this threshold is exceeded, the
endpoint should destroy the TCB and may report the peer endpoint endpoint should destroy the TCB and may report the peer endpoint
unreachable to the upper layer (and thus the association enters the unreachable to the upper layer (and thus the association enters the
CLOSED state). CLOSED state).
skipping to change at page 38, line 34 skipping to change at page 39, line 50
New text: (Section 9.2) New text: (Section 9.2)
--------- ---------
The sender of the SHUTDOWN ACK SHOULD limit the number of The sender of the SHUTDOWN ACK SHOULD limit the number of
retransmissions of the SHUTDOWN ACK chunk to the protocol parameter retransmissions of the SHUTDOWN ACK chunk to the protocol parameter
'Association.Max.Retrans'. If this threshold is exceeded, the 'Association.Max.Retrans'. If this threshold is exceeded, the
endpoint SHOULD destroy the TCB and SHOULD report the peer endpoint endpoint SHOULD destroy the TCB and SHOULD report the peer endpoint
unreachable to the upper layer (and thus the association enters the unreachable to the upper layer (and thus the association enters the
CLOSED state). CLOSED state).
This text is in final form, and is not further updated in this
document.
3.23.3. Solution Description 3.23.3. Solution Description
The inconsistencies are removed by using consistently SHOULD. The inconsistencies are removed by using consistently SHOULD.
3.24. SACK.Delay Not Listed as a Protocol Parameter 3.24. SACK.Delay Not Listed as a Protocol Parameter
3.24.1. Description of the Problem 3.24.1. Description of the Problem
SCTP as specified in [RFC4960] supports delaying SACKs. The timer SCTP as specified in [RFC4960] supports delaying SACKs. The timer
value for this is a parameter and Section 6.2 of [RFC4960] specifies value for this is a parameter and Section 6.2 of [RFC4960] specifies
skipping to change at page 39, line 24 skipping to change at page 40, line 41
--------- ---------
New text: (Section 6.2) New text: (Section 6.2)
--------- ---------
An implementation MUST NOT allow the maximum delay (protocol An implementation MUST NOT allow the maximum delay (protocol
parameter 'SACK.Delay') to be configured to be more than 500 ms. parameter 'SACK.Delay') to be configured to be more than 500 ms.
In other words, an implementation MAY lower the value of In other words, an implementation MAY lower the value of
SACK.Delay below 500 ms but MUST NOT raise it above 500 ms. SACK.Delay below 500 ms but MUST NOT raise it above 500 ms.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 15) Old text: (Section 15)
--------- ---------
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 Max.Burst - 4
skipping to change at page 40, line 14 skipping to change at page 41, line 44
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
HB.Max.Burst - 1 HB.Max.Burst - 1
SACK.Delay - 200 milliseconds SACK.Delay - 200 milliseconds
This text has been modified by multiple errata. It is further
updated in Section 3.32.
3.24.3. Solution Description 3.24.3. Solution Description
The parameter was given a name and added to the list of protocol The parameter was given a name and added to the list of protocol
parameters. parameters.
3.25. Processing of Chunks in an Incoming SCTP Packet 3.25. Processing of Chunks in an Incoming SCTP Packet
3.25.1. Description of the Problem 3.25.1. Description of the Problem
There are a few places in [RFC4960] where the receiver of a packet There are a few places in [RFC4960] where the receiver of a packet
skipping to change at page 40, line 35 skipping to change at page 42, line 21
unclear whether the receiver has to rollback state changes already unclear whether the receiver has to rollback state changes already
performed while processing the packet or not. performed while processing the packet or not.
The intention of [RFC4960] is to process an incoming packet chunk by The intention of [RFC4960] is to process an incoming packet chunk by
chunk and not to perform any prescreening of chunks in the received chunk and not to perform any prescreening of chunks in the received
packet. Thus, by discarding one chunk the receiver also causes packet. Thus, by discarding one chunk the receiver also causes
discarding of all further chunks. discarding of all further chunks.
3.25.2. Text Changes to the Document 3.25.2. Text Changes to the Document
--------- ---------
Old text: (Section 3.2) Old text: (Section 3.2)
--------- ---------
00 - Stop processing this SCTP packet and discard it, do not 00 - Stop processing this SCTP packet and discard it, do not
process any further chunks within it. process any further chunks within it.
01 - Stop processing this SCTP packet and discard it, do not 01 - Stop processing this SCTP packet and discard it, do not
process any further chunks within it, and report the process any further chunks within it, and report the
unrecognized chunk in an 'Unrecognized Chunk Type'. unrecognized chunk in an 'Unrecognized Chunk Type'.
--------- ---------
New text: (Section 3.2) New text: (Section 3.2)
--------- ---------
00 - Stop processing this SCTP packet, discard the unrecognized 00 - Stop processing this SCTP packet, discard the unrecognized
chunk and all further chunks. chunk and all further chunks.
01 - Stop processing this SCTP packet, discard the unrecognized 01 - Stop processing this SCTP packet, discard the unrecognized
chunk and all further chunks, and report the unrecognized chunk and all further chunks, and report the unrecognized
chunk in an 'Unrecognized Chunk Type'. chunk in an 'Unrecognized Chunk Type'.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 11.3) Old text: (Section 11.3)
--------- ---------
It is helpful for some firewalls if they can inspect just the first It is helpful for some firewalls if they can inspect just the first
fragment of a fragmented SCTP packet and unambiguously determine fragment of a fragmented SCTP packet and unambiguously determine
whether it corresponds to an INIT chunk (for further information, whether it corresponds to an INIT chunk (for further information,
please refer to [RFC1858]). Accordingly, we stress the requirements, please refer to [RFC1858]). Accordingly, we stress the requirements,
stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled
skipping to change at page 41, line 40 skipping to change at page 43, line 36
fragment of a fragmented SCTP packet and unambiguously determine fragment of a fragmented SCTP packet and unambiguously determine
whether it corresponds to an INIT chunk (for further information, whether it corresponds to an INIT chunk (for further information,
please refer to [RFC1858]). Accordingly, we stress the requirements, please refer to [RFC1858]). Accordingly, we stress the requirements,
stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled
with any other chunk in a packet, and (2) a packet containing an INIT with any other chunk in a packet, and (2) a packet containing an INIT
chunk MUST have a zero Verification Tag. chunk MUST have a zero Verification Tag.
The receiver of an INIT chunk MUST silently discard the INIT chunk and The receiver of an INIT chunk MUST silently discard the INIT chunk and
all further chunks if the INIT chunk is bundled with other chunks or all further chunks if the INIT chunk is bundled with other chunks or
the packet has a non-zero verification tag. the packet has a non-zero verification tag.
This text is in final form, and is not further updated in this
document.
3.25.3. Solution Description 3.25.3. Solution Description
The new text makes it clear that chunks can be processed from the The new text makes it clear that chunks can be processed from the
beginning to the end and no rollback or pre-screening is required. beginning to the end and no rollback or pre-screening is required.
3.26. CWND Increase in Congestion Avoidance Phase 3.26. CWND Increase in Congestion Avoidance Phase
3.26.1. Description of the Problem 3.26.1. Description of the Problem
[RFC4960] in Section 7.2.2 prescribes to increase cwnd by 1*MTU per [RFC4960] in Section 7.2.2 prescribes to increase cwnd by 1*MTU per
skipping to change at page 42, line 35 skipping to change at page 44, line 34
guidelines for incrementing cwnd during congestion avoidance are: guidelines for incrementing cwnd during congestion avoidance are:
o SCTP MAY increment cwnd by 1*MTU. o SCTP MAY increment cwnd by 1*MTU.
o SCTP SHOULD increment cwnd by one 1*MTU once per RTT when o SCTP SHOULD increment cwnd by one 1*MTU once per RTT when
the sender has cwnd or more bytes of data outstanding for the sender has cwnd or more bytes of data outstanding for
the corresponding transport address. the corresponding transport address.
o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT. o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 7.2.2) Old text: (Section 7.2.2)
--------- ---------
o Whenever cwnd is greater than ssthresh, upon each SACK arrival o Whenever cwnd is greater than ssthresh, upon each SACK arrival
that advances the Cumulative TSN Ack Point, increase that advances the Cumulative TSN Ack Point, increase
partial_bytes_acked by the total number of bytes of all new chunks partial_bytes_acked by the total number of bytes of all new chunks
acknowledged in that SACK including chunks acknowledged by the new acknowledged in that SACK including chunks acknowledged by the new
Cumulative TSN Ack and by Gap Ack Blocks. Cumulative TSN Ack and by Gap Ack Blocks.
skipping to change at page 43, line 24 skipping to change at page 45, line 42
arrival of the SACK the sender had less than cwnd bytes of data arrival of the SACK the sender had less than cwnd bytes of data
outstanding (i.e., before arrival of the SACK, flightsize was less outstanding (i.e., before arrival of the SACK, flightsize was less
than cwnd), reset partial_bytes_acked to cwnd. than cwnd), reset partial_bytes_acked to cwnd.
o When partial_bytes_acked is equal to or greater than cwnd and o When partial_bytes_acked is equal to or greater than cwnd and
before the arrival of the SACK the sender had cwnd or more bytes before the arrival of the SACK the sender had cwnd or more bytes
of data outstanding (i.e., before arrival of the SACK, flightsize of data outstanding (i.e., before arrival of the SACK, flightsize
was greater than or equal to cwnd), partial_bytes_acked is reset was greater than or equal to cwnd), partial_bytes_acked is reset
to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU. to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU.
This text has been modified by multiple errata. It includes
modifications from Section 3.12 and Section 3.22. It is in final
form, and is not further updated in this document.
3.26.3. Solution Description 3.26.3. Solution Description
The basic guidelines for incrementing cwnd during the congestion The basic guidelines for incrementing cwnd during the congestion
avoidance phase are added into Section 7.2.2. The guidelines include avoidance phase are added into Section 7.2.2. The guidelines include
the normative language and are aligned with [RFC5681]. the normative language and are aligned with [RFC5681].
The algorithm from Section 7.2.2 is improved to not allow increasing The algorithm from Section 7.2.2 is improved to not allow increasing
cwnd by more than 1*MTU per RTT. cwnd by more than 1*MTU per RTT.
3.27. Refresh of cwnd and ssthresh after Idle Period 3.27. Refresh of cwnd and ssthresh after Idle Period
skipping to change at page 44, line 38 skipping to change at page 47, line 21
max(cwnd/2, 4*MTU) per RTO. max(cwnd/2, 4*MTU) per RTO.
--------- ---------
New text: (Section 7.2.1) New text: (Section 7.2.1)
--------- ---------
o While the endpoint does not transmit data on a given transport o While the endpoint does not transmit data on a given transport
address, the cwnd of the transport address SHOULD be adjusted to address, the cwnd of the transport address SHOULD be adjusted to
max(cwnd/2, 4*MTU) once per RTO. Before the first cwnd adjustment, max(cwnd/2, 4*MTU) once per RTO. Before the first cwnd adjustment,
the ssthresh of the transport address SHOULD be set to the cwnd. the ssthresh of the transport address SHOULD be set to the cwnd.
This text is in final form, and is not further updated in this
document.
3.27.3. Solution Description 3.27.3. Solution Description
A rule about cwnd adjustment after a sufficiently long idle period is A rule about cwnd adjustment after a sufficiently long idle period is
removed. removed.
The text is updated to describe the ssthresh handling. When the idle The text is updated to describe the ssthresh handling. When the idle
period is detected, the cwnd value is stored to the ssthresh value. period is detected, the cwnd value is stored to the ssthresh value.
3.28. Window Updates After Receiver Window Opens Up 3.28. Window Updates After Receiver Window Opens Up
skipping to change at page 45, line 33 skipping to change at page 48, line 25
An SCTP receiver MUST NOT generate more than one SACK for every An SCTP receiver MUST NOT generate more than one SACK for every
incoming packet, other than to update the offered window as the incoming packet, other than to update the offered window as the
receiving application consumes new data. When the window opens receiving application consumes new data. When the window opens
up, an SCTP receiver SHOULD send additional SACK chunks to update up, an SCTP receiver SHOULD send additional SACK chunks to update
the window even if no new data is received. the window even if no new data is received.
The receiver MUST avoid sending a large number of window updates, The receiver MUST avoid sending a large number of window updates,
in particular large bursts of them. in particular large bursts of them.
One way to achieve this is to send a window update only if the One way to achieve this is to send a window update only if the
window can be increased by at least a quarter of the receive window can be increased by at least a quarter of the receive
buffer size. buffer size of the association.
This text is in final form, and is not further updated in this
document.
3.28.3. Solution Description 3.28.3. Solution Description
The new text makes clear that additional SACK chunks for window The new text makes clear that additional SACK chunks for window
updates should be sent as long as excessive bursts are avoided. updates should be sent as long as excessive bursts are avoided.
3.29. Path of DATA and Reply Chunks 3.29. Path of DATA and Reply Chunks
3.29.1. Description of the Problem 3.29.1. Description of the Problem
skipping to change at page 47, line 5 skipping to change at page 49, line 45
The selection of the destination transport address for packets The selection of the destination transport address for packets
containing SACK chunks is implementation dependent. However, an endpoint containing SACK chunks is implementation dependent. However, an endpoint
SHOULD NOT vary the destination transport address of a SACK when it SHOULD NOT vary the destination transport address of a SACK when it
receives DATA chunks coming from the same source address. receives DATA chunks coming from the same source address.
When acknowledging multiple DATA chunks received in packets When acknowledging multiple DATA chunks received in packets
from different source addresses in a single SACK, the SACK chunk MAY from different source addresses in a single SACK, the SACK chunk MAY
be transmitted to one of the destination transport addresses from be transmitted to one of the destination transport addresses from
which the DATA or control chunks being acknowledged were received. which the DATA or control chunks being acknowledged were received.
This text is in final form, and is not further updated in this
document.
3.29.3. Solution Description 3.29.3. Solution Description
The SACK transmission policy is left implementation dependent but it The SACK transmission policy is left implementation dependent but it
is specified to not vary the destination address of a packet is specified to not vary the destination address of a packet
containing a SACK chunk unless there are reasons for it as it may containing a SACK chunk unless there are reasons for it as it may
negatively impact RTT measurement. negatively impact RTT measurement.
A confusing statement that prescribes to follow the rule for A confusing statement that prescribes to follow the rule for
transmittal of reply chunks when the endpoint is bundling DATA chunks transmittal of reply chunks when the endpoint is bundling DATA chunks
together with the reply chunk is removed. together with the reply chunk is removed.
skipping to change at page 48, line 16 skipping to change at page 51, line 39
A DATA chunk which is classified as lost but which has not been A DATA chunk which is classified as lost but which has not been
retransmitted yet is not in outstanding data. retransmitted yet is not in outstanding data.
o Flightsize: The amount of bytes of outstanding data to a o Flightsize: The amount of bytes of outstanding data to a
particular destination transport address at any given time. particular destination transport address at any given time.
o Congestion window (cwnd): An SCTP variable that limits outstanding o Congestion window (cwnd): An SCTP variable that limits outstanding
data, in number of bytes, a sender can send to a particular data, in number of bytes, a sender can send to a particular
destination transport address before receiving an acknowledgement. destination transport address before receiving an acknowledgement.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 6.1) Old text: (Section 6.1)
--------- ---------
C) When the time comes for the sender to transmit, before sending new C) When the time comes for the sender to transmit, before sending new
DATA chunks, the sender MUST first transmit any outstanding DATA DATA chunks, the sender MUST first transmit any outstanding DATA
chunks that are marked for retransmission (limited by the current chunks that are marked for retransmission (limited by the current
cwnd). cwnd).
--------- ---------
New text: (Section 6.1) New text: (Section 6.1)
--------- ---------
C) When the time comes for the sender to transmit, before sending new C) When the time comes for the sender to transmit, before sending new
DATA chunks, the sender MUST first transmit any DATA chunks that DATA chunks, the sender MUST first transmit any DATA chunks that
are marked for retransmission (limited by the current cwnd). are marked for retransmission (limited by the current cwnd).
This text is in final form, and is not further updated in this
document.
3.30.3. Solution Description 3.30.3. Solution Description
Now Section 1.3, Key Terms, includes explanations of outstanding Now Section 1.3, Key Terms, includes explanations of outstanding
data, data in flight and flightsize key terms. Section 6.1 is data, data in flight and flightsize key terms. Section 6.1 is
corrected to properly use the outstanding data term. corrected to properly use the outstanding data term.
3.31. CWND Degradation due to Max.Burst 3.31. CWND Degradation due to Max.Burst
3.31.1. Description of the Problem 3.31.1. Description of the Problem
skipping to change at page 49, line 36 skipping to change at page 53, line 36
cwnd temporarily as follows: cwnd temporarily as follows:
if ((flightsize + Max.Burst*MTU) < cwnd) if ((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize + Max.Burst*MTU cwnd = flightsize + Max.Burst*MTU
Or it MAY be applied by strictly limiting the number of packets Or it MAY be applied by strictly limiting the number of packets
emitted by the output routine. When calculating the number of emitted by the output routine. When calculating the number of
packets to transmit and particularly using the formula above, packets to transmit and particularly using the formula above,
cwnd SHOULD NOT be changed permanently. cwnd SHOULD NOT be changed permanently.
This text is in final form, and is not further updated in this
document.
3.31.3. Solution Description 3.31.3. Solution Description
The new text clarifies that cwnd should not be changed when applying The new text clarifies that cwnd should not be changed when applying
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. Reduction of RTO.Initial
3.32.1. Description of the Problem 3.32.1. Description of the Problem
[RFC4960] uses 3 seconds as the default value for RTO.Initial in [RFC4960] uses 3 seconds as the default value for RTO.Initial in
accordance with Section 4.3.2.1 of [RFC1122]. [RFC6298] updates accordance with Section 4.3.2.1 of [RFC1122]. [RFC6298] updates
[RFC1122] and lowers the initial value of the retransmission timer [RFC1122] and lowers the initial value of the retransmission timer
from 3 seconds to 1 second. from 3 seconds to 1 second.
3.32.2. Text Changes to the Document 3.32.2. Text Changes to the Document
--------- ---------
skipping to change at page 50, line 25 skipping to change at page 54, line 31
RTO.Max - 60 seconds RTO.Max - 60 seconds
Max.Burst - 4 Max.Burst - 4
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
HB.Max.Burst - 1 HB.Max.Burst - 1
SACK.Delay - 200 milliseconds
--------- ---------
New text: (Section 15) New text: (Section 15)
--------- ---------
The following protocol parameters are RECOMMENDED: The following protocol parameters are RECOMMENDED:
RTO.Initial - 1 second RTO.Initial - 1 second
RTO.Min - 1 second RTO.Min - 1 second
RTO.Max - 60 seconds RTO.Max - 60 seconds
skipping to change at page 50, line 47 skipping to change at page 55, line 5
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
HB.Max.Burst - 1 HB.Max.Burst - 1
SACK.Delay - 200 milliseconds SACK.Delay - 200 milliseconds
This text has been modified by multiple errata. It includes
modifications from Section 3.24. It is in final form, and is not
further updated in this document.
3.32.3. Solution Description 3.32.3. Solution Description
The value RTO.Initial has been lowered to 1 second to be in tune with The value RTO.Initial has been lowered to 1 second to be in tune with
[RFC6298]. [RFC6298].
3.33. Ordering of Bundled SACK and ERROR Chunks 3.33. Ordering of Bundled SACK and ERROR Chunks
3.33.1. Description of the Problem 3.33.1. Description of the Problem
When an SCTP endpoint receives a DATA chunk with an invalid stream When an SCTP endpoint receives a DATA chunk with an invalid stream
skipping to change at page 51, line 43 skipping to change at page 56, line 5
--------- ---------
Every DATA chunk MUST carry a valid stream identifier. If an Every DATA chunk MUST carry a valid stream identifier. If an
endpoint receives a DATA chunk with an invalid stream identifier, it endpoint receives a DATA chunk with an invalid stream identifier, it
SHOULD acknowledge the reception of the DATA chunk following the SHOULD acknowledge the reception of the DATA chunk following the
normal procedure, immediately send an ERROR chunk with cause set to normal procedure, immediately send an ERROR chunk with cause set to
"Invalid Stream Identifier" (see Section 3.3.10), and discard the "Invalid Stream Identifier" (see Section 3.3.10), and discard the
DATA chunk. The endpoint MAY bundle the ERROR chunk and the SACK Chunk DATA chunk. The endpoint MAY bundle the ERROR chunk and the SACK Chunk
in the same packet. in the same packet.
This text is in final form, and is not further updated in this
document.
3.33.3. Solution Description 3.33.3. Solution Description
The unnecessary restriction regarding the ordering of the SACK and The unnecessary restriction regarding the ordering of the SACK and
ERROR chunk has been removed. ERROR chunk has been removed.
3.34. Undefined Parameter Returned by RECEIVE Primitive 3.34. Undefined Parameter Returned by RECEIVE Primitive
3.34.1. Description of the Problem 3.34.1. Description of the Problem
[RFC4960] provides a description of an abstract API. In the [RFC4960] provides a description of an abstract API. In the
definition of the RECEIVE primitive an optional parameter with name definition of the RECEIVE primitive an optional parameter with name
"delivery number" is mentioned. However, no definition of this "delivery number" is mentioned. However, no definition of this
parameter is given in [RFC4960] and the parameter is unnecessary. parameter is given in [RFC4960] and the parameter is unnecessary.
3.34.2. Text Changes to the Document 3.34.2. Text Changes to the Document
--------- ---------
skipping to change at page 52, line 14 skipping to change at page 56, line 25
3.34.1. Description of the Problem 3.34.1. Description of the Problem
[RFC4960] provides a description of an abstract API. In the [RFC4960] provides a description of an abstract API. In the
definition of the RECEIVE primitive an optional parameter with name definition of the RECEIVE primitive an optional parameter with name
"delivery number" is mentioned. However, no definition of this "delivery number" is mentioned. However, no definition of this
parameter is given in [RFC4960] and the parameter is unnecessary. parameter is given in [RFC4960] and the parameter is unnecessary.
3.34.2. Text Changes to the Document 3.34.2. Text Changes to the Document
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1 G))
--------- ---------
G) Receive G) Receive
Format: RECEIVE(association id, buffer address, buffer size Format: RECEIVE(association id, buffer address, buffer size
[,stream id]) [,stream id])
-> byte count [,transport address] [,stream id] [,stream sequence -> byte count [,transport address] [,stream id] [,stream sequence
number] [,partial flag] [,delivery number] [,payload protocol-id] number] [,partial flag] [,delivery number] [,payload protocol-id]
--------- ---------
New text: (Section 10.1) New text: (Section 10.1 G))
--------- ---------
G) Receive G) Receive
Format: RECEIVE(association id, buffer address, buffer size Format: RECEIVE(association id, buffer address, buffer size
[,stream id]) [,stream id])
-> byte count [,transport address] [,stream id] [,stream sequence -> byte count [,transport address] [,stream id] [,stream sequence
number] [,partial flag] [,payload protocol-id] number] [,partial flag] [,payload protocol-id]
This text is in final form, and is not further updated in this
document.
3.34.3. Solution Description 3.34.3. Solution Description
The undefined parameter has been removed. The undefined parameter has been removed.
3.35. DSCP Changes 3.35. DSCP Changes
3.35.1. Description of the Problem 3.35.1. Description of the Problem
The upper layer can change the Differentiated Services Code Point The upper layer can change the Differentiated Services Code Point
(DSCP) used for packets being sent. A change of the DSCP can result (DSCP) used for packets being sent. A change of the DSCP can result
skipping to change at page 53, line 18 skipping to change at page 57, line 32
New text: (Section 7.2.5) New text: (Section 7.2.5)
--------- ---------
7.2.5. Change of Differentiated Services Code Points 7.2.5. Change of Differentiated Services Code Points
SCTP implementations MAY allow an application to configure the SCTP implementations MAY allow an application to configure the
Differentiated Services Code Point (DSCP) used for sending packets. Differentiated Services Code Point (DSCP) used for sending packets.
If a DSCP change might result in outgoing packets being queued in If a DSCP change might result in outgoing packets being queued in
different queues, the congestion control parameters for all affected different queues, the congestion control parameters for all affected
destination addresses MUST be reset to their initial values. destination addresses MUST be reset to their initial values.
--------- This text is in final form, and is not further updated in this
Old text: (Section 10.1) document.
---------
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. ---------
Old text: (Section 10.1 M))
---------
o protocol parameter list - the specific names and values of the Mandatory attributes:
protocol parameters (e.g., Association.Max.Retrans; see Section
15) that the SCTP user wishes to customize.
--------- o association id - local handle to the SCTP association.
New text: (Section 10.1)
---------
M) Set Protocol Parameters 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.
Format: SETPROTOCOLPARAMETERS(association id, ---------
[,destination transport address,] New text: (Section 10.1 M))
protocol parameter list) ---------
-> result
This primitive allows the local SCTP to customize the protocol Mandatory attributes:
parameters.
Mandatory attributes: o association id - local handle to the SCTP association.
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.
o protocol parameter list - the specific names and values of the This text is in final form, and is not further updated in this
protocol parameters (e.g., Association.Max.Retrans; see Section document.
15, or other parameters like the DSCP) that the SCTP user wishes
to customize.
3.35.3. Solution Description 3.35.3. Solution Description
Text describing the required action on DSCP changes has been added. Text describing the required action on DSCP changes has been added.
3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages
3.36.1. Description of the Problem 3.36.1. Description of the Problem
Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6
skipping to change at page 55, line 19 skipping to change at page 59, line 22
code does not indicate "Protocol Unreachable" or code does not indicate "Protocol Unreachable" or
"Fragmentation Needed". "Fragmentation Needed".
--------- ---------
New text: (Appendix C) New text: (Appendix C)
--------- ---------
ICMP3) An implementation SHOULD ignore any ICMP messages where the ICMP3) An implementation SHOULD ignore any ICMP messages where the
code indicates "Port Unreachable". code indicates "Port Unreachable".
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Appendix C) Old text: (Appendix C)
--------- ---------
ICMP9) If the ICMPv6 code is "Destination Unreachable", the ICMP9) If the ICMPv6 code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter. state or alternatively increment the path error counter.
--------- ---------
New text: (Appendix C) New text: (Appendix C)
--------- ---------
ICMP9) If the ICMP type is "Destination Unreachable", the ICMP9) If the ICMP type is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter. state or alternatively increment the path error counter.
This text has been modified by multiple errata. It is further
updated in Section 3.37.
3.36.3. Solution Description 3.36.3. Solution Description
The text has been changed to describe the intended handling of ICMP The text has been changed to describe the intended handling of ICMP
messages indicating that the port number is unreachable by replacing messages indicating that the port number is unreachable by replacing
the third rule. Furthermore, remove the limitation to ICMPv6 in the the third rule. Furthermore, remove the limitation to ICMPv6 in the
ninth rule. ninth rule.
3.37. Handling of Soft Errors 3.37. Handling of Soft Errors
3.37.1. Description of the Problem 3.37.1. Description of the Problem
[RFC1122] defines the handling of soft errors and hard errors for [RFC1122] defines the handling of soft errors and hard errors for
TCP. Appendix C of [RFC4960] only deals with hard errors. TCP. Appendix C of [RFC4960] only deals with hard errors.
3.37.2. Text Changes to the Document 3.37.2. Text Changes to the Document
--------- ---------
Old text: (Appendix C) Old text: (Appendix C)
--------- ---------
ICMP9) If the ICMP type is "Destination Unreachable", the ICMP9) If the ICMPv6 code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter. state or alternatively increment the path error counter.
--------- ---------
New text: (Appendix C) New text: (Appendix C)
--------- ---------
ICMP9) If the ICMP type is "Destination Unreachable", the ICMP9) If the ICMP type is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter. state or alternatively increment the path error counter.
SCTP MAY provide information to the upper layer indicating SCTP MAY provide information to the upper layer indicating
the reception of ICMP messages when reporting a network status the reception of ICMP messages when reporting a network status
change. change.
This text has been modified by multiple errata. It includes
modifications from Section 3.36. It is in final form, and is not
further updated in this document.
3.37.3. Solution Description 3.37.3. Solution Description
Text has been added allowing SCTP to notify the application in case Text has been added allowing SCTP to notify the application in case
of soft errors. of soft errors.
3.38. Honoring CWND 3.38. Honoring CWND
3.38.1. Description of the Problem 3.38.1. Description of the Problem
When using the slow start algorithm, SCTP increases the congestion When using the slow start algorithm, SCTP increases the congestion
skipping to change at page 57, line 23 skipping to change at page 61, line 26
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 + (PMTU - 1) or more bytes given transport address if it has cwnd + (PMTU - 1) or more bytes
of data outstanding to that transport address. If data is of data outstanding to that transport address. If data is
available the sender SHOULD exceed cwnd by up to (PMTU-1) bytes on available the sender SHOULD exceed cwnd by up to (PMTU-1) bytes on
a new data transmission if the flightsize does not currently reach a new data transmission if the flightsize does not currently reach
cwnd. The breach of cwnd MUST constitute one packet only. cwnd. The breach of cwnd MUST constitute one packet only.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 7.2.1) Old text: (Section 7.2.1)
--------- ---------
o Whenever cwnd is greater than zero, the endpoint is allowed to o Whenever cwnd is greater than zero, the endpoint is allowed to
have cwnd bytes of data outstanding on that transport address. have cwnd bytes of data outstanding on that transport address.
--------- ---------
New text: (Section 7.2.1) New text: (Section 7.2.1)
--------- ---------
o Whenever cwnd is greater than zero, the endpoint is allowed to o Whenever cwnd is greater than zero, the endpoint is allowed to
have cwnd bytes of data outstanding on that transport address. have cwnd bytes of data outstanding on that transport address.
A limited overbooking as described in B) of Section 6.1 SHOULD A limited overbooking as described in B) of Section 6.1 SHOULD
be supported. be supported.
This text is in final form, and is not further updated in this
document.
3.38.3. Solution Description 3.38.3. Solution Description
Text was added to clarify how the cwnd limit should be handled. Text was added to clarify how the cwnd limit should be handled.
3.39. Zero Window Probing 3.39. Zero Window Probing
3.39.1. Description of the Problem 3.39.1. Description of the Problem
The text describing zero window probing was not clearly handling the 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 case where the window was not zero, but too small for the next DATA
skipping to change at page 58, line 48 skipping to change at page 63, line 45
allows the sender to probe for a change in rwnd that the sender 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 missed due to the SACK's having been lost in transit from the data
receiver to the data sender. receiver to the data sender.
When the receiver has no buffer space, this probe is When the receiver has no buffer space, this probe is
called a zero window probe. Note that a zero window probe SHOULD called a zero window probe. Note that a zero window probe SHOULD
only be sent when all outstanding DATA chunks have been only be sent when all outstanding DATA chunks have been
cumulatively acknowledged and no DATA chunks are in flight. Zero cumulatively acknowledged and no DATA chunks are in flight. Zero
window probing MUST be supported. window probing MUST be supported.
This text is in final form, and is not further updated in this
document.
3.39.3. Solution Description 3.39.3. Solution Description
The terminology is used in a cleaner way. The terminology is used in a cleaner way.
3.40. Updating References Regarding ECN 3.40. Updating References Regarding ECN
3.40.1. Description of the Problem 3.40.1. Description of the Problem
[RFC4960] refers for ECN only to [RFC3168], which will be updated by [RFC4960] refers for ECN only to [RFC3168], which will be updated by
[RFC8311]. This needs to be reflected when referring to ECN. [RFC8311]. This needs to be reflected when referring to ECN.
3.40.2. Text Changes to the Document 3.40.2. Text Changes to the Document
--------- ---------
Old text: (Appendix A) Old text: (Appendix A)
--------- ---------
ECN [RFC3168] describes a proposed extension to IP that details a ECN [RFC3168] describes a proposed extension to IP that details a
method to become aware of congestion outside of datagram loss. method to become aware of congestion outside of datagram loss.
--------- ---------
New text: (Appendix A) New text: (Appendix A)
--------- ---------
ECN as specified in [RFC3168] updated by [RFC8311] describes an ECN as specified in [RFC3168] updated by [RFC8311] describes an
extension to IP that details a method to become aware of congestion extension to IP that details a method to become aware of congestion
outside of datagram loss. outside of datagram loss.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Appendix A) Old text: (Appendix A)
--------- ---------
In general, [RFC3168] should be followed with the following In general, [RFC3168] should be followed with the following
exceptions. exceptions.
--------- ---------
New text: (Appendix A) New text: (Appendix A)
--------- ---------
In general, [RFC3168] updated by [RFC8311] SHOULD be followed with the In general, [RFC3168] updated by [RFC8311] SHOULD be followed with the
following exceptions. following exceptions.
--------- This text is in final form, and is not further updated in this
Old text: (Appendix A) document.
---------
[RFC3168] details negotiation of ECN during the SYN and SYN-ACK ---------
stages of a TCP connection. Old text: (Appendix A)
---------
--------- [RFC3168] details negotiation of ECN during the SYN and SYN-ACK
New text: (Appendix A) stages of a TCP connection.
---------
[RFC3168] updated by [RFC8311] details negotiation of ECN during the ---------
SYN and SYN-ACK stages of a TCP connection. New text: (Appendix A)
---------
--------- [RFC3168] updated by [RFC8311] details negotiation of ECN during the
Old text: (Appendix A) SYN and SYN-ACK stages of a TCP connection.
---------
[RFC3168] details a specific bit for a receiver to send back in its This text is in final form, and is not further updated in this
TCP acknowledgements to notify the sender of the Congestion document.
Experienced (CE) bit having arrived from the network.
--------- ---------
New text: (Appendix A) Old text: (Appendix A)
--------- ---------
[RFC3168] updated by [RFC8311] details a specific bit for a receiver [RFC3168] details a specific bit for a receiver to send back in its
to send back in its TCP acknowledgements to notify the sender of the TCP acknowledgements to notify the sender of the Congestion
Congestion Experienced (CE) bit having arrived from the network. Experienced (CE) bit having arrived from the network.
--------- ---------
Old text: (Appendix A) New text: (Appendix A)
--------- ---------
[RFC3168] details a specific bit for a sender to send in the header [RFC3168] updated by [RFC8311] details a specific bit for a receiver
of its next outbound TCP segment to indicate to its peer that it has to send back in its TCP acknowledgements to notify the sender of the
reduced its congestion window. Congestion Experienced (CE) bit having arrived from the network.
---------
New text: (Appendix A)
---------
[RFC3168] updated by [RFC8311] details a specific bit for a sender This text is in final form, and is not further updated in this
to send in the header of its next outbound TCP segment to indicate to document.
its peer that it has reduced its congestion window.
---------
Old text: (Appendix A)
---------
[RFC3168] details a specific bit for a sender to send in the header
of its next outbound TCP segment to indicate to its peer that it has
reduced its congestion window.
---------
New text: (Appendix A)
---------
[RFC3168] updated by [RFC8311] details a specific bit for a sender
to send in the header of its next outbound TCP segment to indicate to
its peer that it has reduced its congestion window.
This text is in final form, and is not further updated in this
document.
3.40.3. Solution Description 3.40.3. Solution Description
References to [RFC8311] have been added. While there, some References to [RFC8311] have been added. While there, some
wordsmithing has been performed. wordsmithing has been performed.
3.41. Host Name Address Parameter Deprecated 3.41. Host Name Address Parameter Deprecated
3.41.1. Description of the Problem 3.41.1. Description of the Problem
skipping to change at page 61, line 34 skipping to change at page 67, line 23
--------- ---------
New text: (Section 3.3.2) New text: (Section 3.3.2)
--------- ---------
Note 3: An INIT chunk MUST NOT contain the Host Name Address Note 3: An INIT chunk MUST NOT contain the Host Name Address
parameter. The receiver of an INIT chunk containing a Host Name parameter. The receiver of an INIT chunk containing a Host Name
Address parameter MUST send an ABORT and MAY include an Error Cause Address parameter MUST send an ABORT and MAY include an Error Cause
indicating an Unresolvable Address. indicating an Unresolvable Address.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 3.3.2.1) Old text: (Section 3.3.2.1)
--------- ---------
The sender of INIT uses this parameter to pass its Host Name (in The sender of INIT uses this parameter to pass its Host Name (in
place of its IP addresses) to its peer. The peer is responsible for place of its IP addresses) to its peer. The peer is responsible for
resolving the name. Using this parameter might make it more likely resolving the name. Using this parameter might make it more likely
for the association to work across a NAT box. for the association to work across a NAT box.
--------- ---------
New text: (Section 3.3.2.1) New text: (Section 3.3.2.1)
--------- ---------
The sender of an INIT chunk MUST NOT include this parameter. The The sender of an INIT chunk MUST NOT include this parameter. The
usage of the Host Name Address parameter is deprecated. usage of the Host Name Address parameter is deprecated.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 3.3.2.1) Old text: (Section 3.3.2.1)
--------- ---------
Address Type: 16 bits (unsigned integer) Address Type: 16 bits (unsigned integer)
This is filled with the type value of the corresponding address This is filled with the type value of the corresponding address
TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11). TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11).
--------- ---------
New text: (Section 3.3.2.1) New text: (Section 3.3.2.1)
--------- ---------
Address Type: 16 bits (unsigned integer) Address Type: 16 bits (unsigned integer)
skipping to change at page 62, line 18 skipping to change at page 68, line 23
--------- ---------
New text: (Section 3.3.2.1) New text: (Section 3.3.2.1)
--------- ---------
Address Type: 16 bits (unsigned integer) Address Type: 16 bits (unsigned integer)
This is filled with the type value of the corresponding address This is filled with the type value of the corresponding address
TLV (e.g., IPv4 = 5, IPv6 = 6). The value indicating the Host TLV (e.g., IPv4 = 5, IPv6 = 6). The value indicating the Host
Name Address parameter (Host name = 11) MUST NOT be used. Name Address parameter (Host name = 11) MUST NOT be used.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 3.3.3) Old text: (Section 3.3.3)
--------- ---------
Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name
Address parameter. Moreover, the sender of the INIT ACK MUST NOT Address parameter. Moreover, the sender of the INIT ACK MUST NOT
combine any other address types with the Host Name Address in the combine any other address types with the Host Name Address in the
INIT ACK. The receiver of the INIT ACK MUST ignore any other address INIT ACK. The receiver of the INIT ACK MUST ignore any other address
types if the Host Name Address parameter is present. types if the Host Name Address parameter is present.
--------- ---------
New text: (Section 3.3.3) New text: (Section 3.3.3)
--------- ---------
Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address
parameter. The receiver of INIT ACK chunks containing a Host Name parameter. The receiver of INIT ACK chunks containing a Host Name
Address parameter MUST send an ABORT and MAY include an Error Cause Address parameter MUST send an ABORT and MAY include an Error Cause
indicating an Unresolvable Address. indicating an Unresolvable Address.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 5.1.2) Old text: (Section 5.1.2)
--------- ---------
B) If there is a Host Name parameter present in the received INIT or B) If there is a Host Name parameter present in the received INIT or
INIT ACK chunk, the endpoint shall resolve that host name to a INIT ACK chunk, the endpoint shall resolve that host name to a
list of IP address(es) and derive the transport address(es) of list of IP address(es) and derive the transport address(es) of
this peer by combining the resolved IP address(es) with the SCTP this peer by combining the resolved IP address(es) with the SCTP
source port. source port.
skipping to change at page 63, line 41 skipping to change at page 70, line 5
--------- ---------
New text: (Section 5.1.2) New text: (Section 5.1.2)
--------- ---------
B) If there is a Host Name parameter present in the received INIT or B) If there is a Host Name parameter present in the received INIT or
INIT ACK chunk, the endpoint MUST immediately send an ABORT and INIT ACK chunk, the endpoint MUST immediately send an ABORT and
MAY include an Error Cause indicating an Unresolvable Address to MAY include an Error Cause indicating an Unresolvable Address to
its peer. The ABORT SHALL be sent to the source IP address its peer. The ABORT SHALL be sent to the source IP address
from which the last peer packet was received. from which the last peer packet was received.
This text is in final form, and is not further updated in this
document.
--------- ---------
Old text: (Section 11.2.4.1) Old text: (Section 11.2.4.1)
--------- ---------
The use of the host name feature in the INIT chunk could be used to The use of the host name feature in the INIT chunk could be used to
flood a target DNS server. A large backlog of DNS queries, resolving flood a target DNS server. A large backlog of DNS queries, resolving
the host name received in the INIT chunk to IP addresses, could be the host name received in the INIT chunk to IP addresses, could be
accomplished by sending INITs to multiple hosts in a given domain. accomplished by sending INITs to multiple hosts in a given domain.
In addition, an attacker could use the host name feature in an In addition, an attacker could use the host name feature in an
indirect attack on a third party by sending large numbers of INITs to indirect attack on a third party by sending large numbers of INITs to
skipping to change at page 64, line 21 skipping to change at page 70, line 36
--------- ---------
New text: (Section 11.2.4.1) New text: (Section 11.2.4.1)
--------- ---------
The support of the Host Name Address parameter has been removed from The support of the Host Name Address parameter has been removed from
the protocol. Endpoints receiving INIT or INIT ACK chunks containing the protocol. Endpoints receiving INIT or INIT ACK chunks containing
the Host Name Address parameter MUST send an ABORT chunk in response the Host Name Address parameter MUST send an ABORT chunk in response
and MAY include an Error Cause indicating an Unresolvable Address. and MAY include an Error Cause indicating an Unresolvable Address.
This text is in final form, and is not further updated in this
document.
3.41.3. Solution Description 3.41.3. Solution Description
The usage of the Host Name Address parameter has been deprecated. The usage of the Host Name Address parameter has been deprecated.
3.42. Conflicting Text Regarding the Supported Address Types Parameter 3.42. Conflicting Text Regarding the Supported Address Types Parameter
3.42.1. Description of the Problem 3.42.1. Description of the Problem
When receiving an SCTP packet containing an INIT chunk sent from an When receiving an SCTP packet containing an INIT chunk sent from an
address for which the corresponding address type is not listed in the address for which the corresponding address type is not listed in the
skipping to change at page 65, line 25 skipping to change at page 71, line 28
its peer. its peer.
--------- ---------
New text: (Section 5.1.2) New text: (Section 5.1.2)
--------- ---------
The sender of INIT chunks MAY include a 'Supported Address Types' The sender of INIT chunks MAY include a 'Supported Address Types'
parameter in the INIT to indicate what types of addresses are parameter in the INIT to indicate what types of addresses are
acceptable. acceptable.
This text is in final form, and is not further updated in this
document.
3.42.3. Solution Description 3.42.3. Solution Description
The conflicting text has been removed. The conflicting text has been removed.
3.43. Integration of RFC 6096 3.43. Integration of RFC 6096
3.43.1. Description of the Problem 3.43.1. Description of the Problem
[RFC6096] updates [RFC4960] by adding a Chunk Flags Registry. This [RFC6096] updates [RFC4960] by adding a Chunk Flags Registry. This
should be integrated into the base specification. should be integrated into the base specification.
skipping to change at page 66, line 46 skipping to change at page 72, line 50
d) A detailed procedural description of the use of the new chunk d) A detailed procedural description of the use of the new chunk
type within the operation of the protocol. type within the operation of the protocol.
The last chunk type (255) is reserved for future extension if The last chunk type (255) is reserved for future extension if
necessary. necessary.
For each new chunk type, IANA creates a registration table for the For each new chunk type, IANA creates a registration table for the
chunk flags of that type. The procedure for registering particular chunk flags of that type. The procedure for registering particular
chunk flags is described in the following Section 14.2. chunk flags is described in the following Section 14.2.
This text has been modified by multiple errata. It includes
modifications from Section 3.3. It is in final form, and is not
further updated in this document.
--------- ---------
New text: (Section 14.2) New text: (Section 14.2)
--------- ---------
14.2. New IETF Chunk Flags Registration 14.2. New IETF Chunk Flags Registration
The assignment of new chunk flags is done through an RFC required The assignment of new chunk flags is done through an RFC required
action, as defined in [RFC8126]. Documentation of the chunk flags action, as defined in [RFC8126]. Documentation of the chunk flags
MUST contain the following information: MUST contain the following information:
a) A name for the new chunk flag; a) A name for the new chunk flag;
b) A detailed procedural description of the use of the new chunk b) A detailed procedural description of the use of the new chunk
flag within the operation of the protocol. It MUST be considered flag within the operation of the protocol. It MUST be considered
that implementations not supporting the flag will send '0' on that implementations not supporting the flag will send '0' on
transmit and just ignore it on receipt. transmit and just ignore it on receipt.
skipping to change at page 67, line 19 skipping to change at page 73, line 26
b) A detailed procedural description of the use of the new chunk b) A detailed procedural description of the use of the new chunk
flag within the operation of the protocol. It MUST be considered flag within the operation of the protocol. It MUST be considered
that implementations not supporting the flag will send '0' on that implementations not supporting the flag will send '0' on
transmit and just ignore it on receipt. transmit and just ignore it on receipt.
IANA selects a chunk flags value. This MUST be one of 0x01, 0x02, IANA selects a chunk flags value. This MUST be one of 0x01, 0x02,
0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within
the chunk flag values for the specific chunk type. the chunk flag values for the specific chunk type.
This text is in final form, and is not further updated in this
document.
Please note that Sections 14.2, 14.3, 14.4, and 14.5 need to be Please note that Sections 14.2, 14.3, 14.4, and 14.5 need to be
renumbered. renumbered.
3.43.3. Solution Description 3.43.3. Solution Description
[RFC6096] was integrated and the reference updated to [RFC8126]. [RFC6096] was integrated and the reference updated to [RFC8126].
3.44. Integration of RFC 6335 3.44. Integration of RFC 6335
3.44.1. Description of the Problem 3.44.1. Description of the Problem
skipping to change at page 69, line 18 skipping to change at page 75, line 27
SCTP services can use contact port numbers to provide service to SCTP services can use contact port numbers to provide service to
unknown callers, as in TCP and UDP. IANA is therefore requested to unknown callers, as in TCP and UDP. IANA is therefore requested to
open the existing Port Numbers registry for SCTP using the following open the existing Port Numbers registry for SCTP using the following
rules, which we intend to mesh well with existing Port Numbers rules, which we intend to mesh well with existing Port Numbers
registration procedures. An IESG-appointed Expert Reviewer supports registration procedures. An IESG-appointed Expert Reviewer supports
IANA in evaluating SCTP port allocation requests, according to the IANA in evaluating SCTP port allocation requests, according to the
procedure defined in [RFC8126]. The details of this process are procedure defined in [RFC8126]. The details of this process are
defined in [RFC6335]. defined in [RFC6335].
This text is in final form, and is not further updated in this
document.
3.44.3. Solution Description 3.44.3. Solution Description
[RFC6335] was integrated and the reference was updated to [RFC8126]. [RFC6335] was integrated and the reference was updated to [RFC8126].
3.45. Integration of RFC 7053 3.45. Integration of RFC 7053
3.45.1. Description of the Problem 3.45.1. Description of the Problem
[RFC7053] updates [RFC4960] by adding the I bit to the DATA chunk. [RFC7053] updates [RFC4960] by adding the I bit to the DATA chunk.
This should be integrated into the base specification. This should be integrated into the base specification.
skipping to change at page 70, line 38 skipping to change at page 77, line 4
Res: 4 bits Res: 4 bits
SHOULD be set to all '0's and ignored by the receiver. SHOULD be set to all '0's and ignored by the receiver.
I bit: 1 bit I bit: 1 bit
The (I)mmediate Bit MAY be set by the sender, whenever the sender of The (I)mmediate Bit MAY be set by the sender, whenever the sender of
a DATA chunk can benefit from the corresponding SACK chunk being sent a DATA chunk can benefit from the corresponding SACK chunk being sent
back without delay. See [RFC7053] for a discussion about back without delay. See [RFC7053] for a discussion about
This text is in final form, and is not further updated in this
document.
New text: (Append to Section 6.1) ---------
New text: (Append to Section 6.1)
---------
Whenever the sender of a DATA chunk can benefit from the Whenever the sender of a DATA chunk can benefit from the
corresponding SACK chunk being sent back without delay, the sender corresponding SACK chunk being sent back without delay, the sender
MAY set the I bit in the DATA chunk header. Please note that why the MAY set the I bit in the DATA chunk header. Please note that why the
sender has set the I bit is irrelevant to the receiver. sender has set the I bit is irrelevant to the receiver.
Reasons for setting the I bit include, but are not limited to (see Reasons for setting the I bit include, but are not limited to (see
Section 4 of [RFC7053] for the benefits): Section 4 of [RFC7053] for the benefits):
o The application requests to set the I bit of the last DATA chunk o The application requests to set the I bit of the last DATA chunk
of a user message when providing the user message to the SCTP of a user message when providing the user message to the SCTP
implementation (see Section 7). implementation (see Section 7).
o The sender is in the SHUTDOWN-PENDING state. o The sender is in the SHUTDOWN-PENDING state.
o The sending of a DATA chunk fills the congestion or receiver o The sending of a DATA chunk fills the congestion or receiver
window. window.
Old text: (Section 6.2) This text is in final form, and is not further updated in this
document.
Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. ---------
Therefore, the endpoint should use a SACK instead of the SHUTDOWN Old text: (Section 6.2)
chunk to acknowledge DATA chunks received out of order. ---------
New text: (Section 6.2) Note: The SHUTDOWN chunk does not contain Gap Ack Block fields.
Therefore, the endpoint should use a SACK instead of the SHUTDOWN
chunk to acknowledge DATA chunks received out of order.
Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. ---------
Therefore, the endpoint SHOULD use a SACK instead of the SHUTDOWN New text: (Section 6.2)
chunk to acknowledge DATA chunks received out of order. ---------
Upon receipt of an SCTP packet containing a DATA chunk with the I bit Note: The SHUTDOWN chunk does not contain Gap Ack Block fields.
set, the receiver SHOULD NOT delay the sending of the corresponding Therefore, the endpoint SHOULD use a SACK instead of the SHUTDOWN
SACK chunk, i.e., the receiver SHOULD immediately respond with the chunk to acknowledge DATA chunks received out of order.
corresponding SACK chunk.
Old text: (Section 10.1) Upon receipt of an SCTP packet containing a DATA chunk with the I bit
set, the receiver SHOULD NOT delay the sending of the corresponding
SACK chunk, i.e., the receiver SHOULD immediately respond with the
corresponding SACK chunk.
E) Send Please note that this change is only about adding a paragraph.
Format: SEND(association id, buffer address, byte count [,context] This text is in final form, and is not further updated in this
[,stream id] [,life time] [,destination transport address] document.
[,unordered flag] [,no-bundle flag] [,payload protocol-id] )
-> result
New text: (Section 10.1) ---------
Old text: (Section 10.1 E))
---------
E) Send E) Send
Format: SEND(association id, buffer address, byte count [,context] Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address] [,stream id] [,life time] [,destination transport address]
[,unordered flag] [,no-bundle flag] [,payload protocol-id] )
-> result
[,unordered flag] [,no-bundle flag] [,payload protocol-id] ---------
[,sack immediately] ) New text: (Section 10.1 E))
-> result ---------
New text: (Append optional parameter in Subsection E of Section 10.1) E) Send
o sack immediately - set the I bit on the last DATA chunk used for Format: SEND(association id, buffer address, byte count [,context]
sending buffer. [,stream id] [,life time] [,destination transport address]
[,unordered flag] [,no-bundle flag] [,payload protocol-id]
[,sack immediately] )
-> result
Please note that the change in Section 6.2 is only about adding a This text is in final form, and is not further updated in this
paragraph. document.
---------
New text: (Append optional parameter in Subsection E of Section 10.1)
---------
o sack immediately - set the I bit on the last DATA chunk used for
sending buffer.
This text is in final form, and is not further updated in this
document.
3.45.3. Solution Description 3.45.3. Solution Description
[RFC7053] was integrated. [RFC7053] was integrated.
3.46. CRC32c Code Improvements 3.46. CRC32c Code Improvements
3.46.1. Description of the Problem 3.46.1. Description of the Problem
The code given for the CRC32c computations uses types like long which The code given for the CRC32c computations uses types like long which
may have different length on different operating systems or may have different length on different operating systems or
processors. Therefore, the code is changed to use specific types processors. Therefore, the code is changed to use specific types
like uint32_t. like uint32_t.
While there, fix also some syntax errors and a comment. While there, fix also some syntax errors and a comment.
3.46.2. Text Changes to the Document 3.46.2. Text Changes to the Document
--------- ---------
Old text: (Appendix B) Old text: (Appendix C)
--------- ---------
/*************************************************************/ /*************************************************************/
/* Note Definition for Ross Williams table generator would */ /* Note Definition for Ross Williams table generator would */
/* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */ /* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */
/* For Mr. Williams direct calculation code use the settings */ /* For Mr. Williams direct calculation code use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */ /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */ /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */
/*************************************************************/ /*************************************************************/
/* Example of the crc table file */ /* Example of the crc table file */
skipping to change at page 76, line 23 skipping to change at page 83, line 4
0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL, 0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL,
0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL, 0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL,
0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL, 0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL,
0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL, 0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL,
0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL, 0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL,
0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL, 0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL,
0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL, 0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL,
}; };
#endif #endif
This text has been modified by multiple errata. It includes
modifications from Section 3.10. It is in final form, and is not
further updated in this document.
--------- ---------
Old text: (Appendix B) Old text: (Appendix C)
--------- ---------
/* Example of table build routine */ /* Example of table build routine */
#include <stdio.h> #include <stdio.h>
#include <stdlib.h> #include <stdlib.h>
#define OUTPUT_FILE "crc32cr.h" #define OUTPUT_FILE "crc32cr.h"
#define CRC32C_POLY 0x1EDC6F41L #define CRC32C_POLY 0x1EDC6F41L
FILE *tf; FILE *tf;
skipping to change at page 79, line 33 skipping to change at page 86, line 18
} }
fprintf(tf, "};\n\n#endif\n"); fprintf(tf, "};\n\n#endif\n");
if (fclose (tf) != 0) if (fclose (tf) != 0)
printf("Unable to close <%s>.", OUTPUT_FILE); printf("Unable to close <%s>.", OUTPUT_FILE);
else else
printf("\nThe CRC-32c table has been written to <%s>.\n", printf("\nThe CRC-32c table has been written to <%s>.\n",
OUTPUT_FILE); OUTPUT_FILE);
} }
This text has been modified by multiple errata. It includes
modifications from Section 3.10. It is in final form, and is not
further updated in this document.
--------- ---------
Old text: (Appendix B) Old text: (Appendix C)
--------- ---------
/* Example of crc insertion */ /* Example of crc insertion */
#include "crc32cr.h" #include "crc32cr.h"
unsigned long unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length) generate_crc32c(unsigned char *buffer, unsigned int length)
{ {
unsigned int i; unsigned int i;
skipping to change at page 82, line 41 skipping to change at page 89, line 33
/* save and zero checksum */ /* save and zero checksum */
message = (SCTP_message *)buffer; message = (SCTP_message *)buffer;
original_crc32 = ntohl(message->common_header.checksum); original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L; message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer, length); crc32 = generate_crc32c(buffer, length);
return ((original_crc32 == crc32)? 1 : -1); return ((original_crc32 == crc32)? 1 : -1);
} }
<CODE ENDS> <CODE ENDS>
This text has been modified by multiple errata. It includes
modifications from Section 3.5 and Section 3.10. It is in final
form, and is not further updated in this document.
3.46.3. Solution Description 3.46.3. Solution Description
The code was changed to use platform independent types. The code was changed to use platform independent types.
3.47. Clarification of Gap Ack Blocks in SACK Chunks 3.47. Clarification of Gap Ack Blocks in SACK Chunks
3.47.1. Description of the Problem 3.47.1. Description of the Problem
The Gap Ack Blocks in the SACK chunk are intended to be isolated. The Gap Ack Blocks in the SACK chunk are intended to be isolated.
However, this is not mentioned with normative text. However, this is not mentioned with normative text.
This issue was reported as part of an Errata for [RFC4960] with This issue was reported as part of an Errata for [RFC4960] with
Errata ID 5202. Errata ID 5202.
3.47.2. Text Changes to the Document 3.47.2. Text Changes to the Document
skipping to change at page 83, line 36 skipping to change at page 90, line 29
--------- ---------
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack
Block acknowledges a subsequence of TSNs received following a break Block acknowledges a subsequence of TSNs received following a break
in the sequence of received TSNs. The Gap Ack Blocks SHOULD be isolated. in the sequence of received TSNs. The Gap Ack Blocks SHOULD be isolated.
This means that the TSN just before each Gap Ack Block and the TSN just This means that the TSN just before each Gap Ack Block and the TSN just
after each Gap Ack Block has not been received. By definition, all TSNs after each Gap Ack Block has not been received. By definition, all TSNs
acknowledged by Gap Ack Blocks are greater than the value of the acknowledged by Gap Ack Blocks are greater than the value of the
Cumulative TSN Ack. Cumulative TSN Ack.
Old text: (Section 3.3.4) This text is in final form, and is not further updated in this
document.
Gap Ack Blocks: ---------
Old text: (Section 3.3.4)
---------
These fields contain the Gap Ack Blocks. They are repeated for Gap Ack Blocks:
each Gap Ack Block up to the number of Gap Ack Blocks defined in
the Number of Gap Ack Blocks field. All DATA chunks with TSNs
greater than or equal to (Cumulative TSN Ack + Gap Ack Block
Start) and less than or equal to (Cumulative TSN Ack + Gap Ack
Block End) of each Gap Ack Block are assumed to have been received
correctly.
New text: (Section 3.3.4) These fields contain the Gap Ack Blocks. They are repeated for
each Gap Ack Block up to the number of Gap Ack Blocks defined in
the Number of Gap Ack Blocks field. All DATA chunks with TSNs
greater than or equal to (Cumulative TSN Ack + Gap Ack Block
Start) and less than or equal to (Cumulative TSN Ack + Gap Ack
Block End) of each Gap Ack Block are assumed to have been received
correctly.
Gap Ack Blocks: ---------
New text: (Section 3.3.4)
---------
These fields contain the Gap Ack Blocks. They are repeated for Gap Ack Blocks:
each Gap Ack Block up to the number of Gap Ack Blocks defined in
the Number of Gap Ack Blocks field. All DATA chunks with TSNs These fields contain the Gap Ack Blocks. They are repeated for
greater than or equal to (Cumulative TSN Ack + Gap Ack Block each Gap Ack Block up to the number of Gap Ack Blocks defined in
Start) and less than or equal to (Cumulative TSN Ack + Gap Ack the Number of Gap Ack Blocks field. All DATA chunks with TSNs
Block End) of each Gap Ack Block are assumed to have been received greater than or equal to (Cumulative TSN Ack + Gap Ack Block
correctly. Gap Ack Blocks SHOULD be isolated. That means that Start) and less than or equal to (Cumulative TSN Ack + Gap Ack
the DATA chunks with TSN equal to (Cumulative TSN Ack + Gap Ack Block End) of each Gap Ack Block are assumed to have been received
Block Start - 1) and (Cumulative TSN Ack + Gap Ack Block End + 1) correctly. Gap Ack Blocks SHOULD be isolated. That means that
have not been received. the DATA chunks with TSN equal to (Cumulative TSN Ack + Gap Ack
Block Start - 1) and (Cumulative TSN Ack + Gap Ack Block End + 1)
have not been received.
This text is in final form, and is not further updated in this
document.
3.47.3. Solution Description 3.47.3. Solution Description
Normative text describing the intended usage of Gap Ack Blocks has Normative text describing the intended usage of Gap Ack Blocks has
been added. been added.
3.48. Handling of SSN Wrap Arounds 3.48. Handling of SSN Wrap Arounds
3.48.1. Description of the Problem 3.48.1. Description of the Problem
skipping to change at page 85, line 5 skipping to change at page 92, line 25
--------- ---------
New text: (Section 6.1) New text: (Section 6.1)
--------- ---------
Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 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. 1 above the beginning TSN of the current send window.
Note: For each stream, the data sender SHOULD NOT have more than 2**16-1 Note: For each stream, the data sender SHOULD NOT have more than 2**16-1
ordered user messages in the current send window. ordered user messages in the current send window.
This text is in final form, and is not further updated in this
document.
3.48.3. Solution Description 3.48.3. Solution Description
The data sender is required to limit the number of ordered user The data sender is required to limit the number of ordered user
messages within the current send window. messages within the current send window.
3.49. Update RFC 2119 Boilerplate 3.49. Update RFC 2119 Boilerplate
3.49.1. Description of the Problem 3.49.1. Description of the Problem
The text to be used to refer to the [RFC2119] terms has been updated The text to be used to refer to the [RFC2119] terms has been updated
skipping to change at page 85, line 37 skipping to change at page 93, line 22
--------- ---------
New text: (Section 2) New text: (Section 2)
--------- ---------
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This text is in final form, and is not further updated in this
document.
3.49.3. Solution Description 3.49.3. Solution Description
The text has been updated to the one specified in [RFC8174]. The text has been updated to the one specified in [RFC8174].
3.50. Missed Text Removal 3.50. Missed Text Removal
3.50.1. Description of the Problem 3.50.1. Description of the Problem
When integrating the changes to Section 7.2.4 of [RFC2960] as When integrating the changes to Section 7.2.4 of [RFC2960] as
described in Section 2.8.2 of [RFC4460] some text was not removed and described in Section 2.8.2 of [RFC4460] some text was not removed and
skipping to change at page 86, line 23 skipping to change at page 94, line 20
consecutive SACK reporting the TSN hole. After reaching 3 and consecutive SACK reporting the TSN hole. After reaching 3 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)
--------- ---------
This text is in final form, and is not further updated in this
document.
3.50.3. Solution Description 3.50.3. Solution Description
The text has finally been removed. The text has finally been removed.
4. IANA Considerations 4. IANA Considerations
Section 3.44 of this document updates the port number registry for Section 3.44 of this document updates the port number registry for
SCTP to be consistent with [RFC6335]. IANA is requested to review SCTP to be consistent with [RFC6335]. IANA is requested to review
Section 3.44. Section 3.44.
IANA is only requested to check if it is OK to make the proposed text IANA is only requested to check if it is OK to make the proposed text
change in an upcoming standards track document that updates[RFC4960]. change in an upcoming standards track document that updates
IANA is not asked to perform any other action and this document does [RFC4960]. IANA is not asked to perform any other action and this
not request IANA to make a change to any registry. document does not request IANA to make a change to any registry.
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, Spencer Dawkins, Gorry Fairhurst, Benjamin Kaduk, Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst, Benjamin Kaduk,
 End of changes. 182 change blocks. 
326 lines changed or deleted 528 lines changed or added

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