draft-ietf-tsvwg-rfc4960-errata-03.txt   draft-ietf-tsvwg-rfc4960-errata-04.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Netflix, Inc. Internet-Draft Netflix, Inc.
Intended status: Informational M. Tuexen Intended status: Informational M. Tuexen
Expires: May 3, 2018 Muenster Univ. of Appl. Sciences Expires: May 17, 2018 Muenster Univ. of Appl. Sciences
M. Proshin M. Proshin
Ericsson Ericsson
October 30, 2017 November 13, 2017
RFC 4960 Errata and Issues RFC 4960 Errata and Issues
draft-ietf-tsvwg-rfc4960-errata-03.txt draft-ietf-tsvwg-rfc4960-errata-04.txt
Abstract Abstract
This document is a compilation of issues found since the publication This document is a compilation of issues found since the publication
of RFC4960 in September 2007 based on experience with implementing, of RFC4960 in September 2007 based on experience with implementing,
testing, and using SCTP along with the suggested fixes. This testing, and using SCTP along with the suggested fixes. This
document provides deltas to RFC4960 and is organized in a time based document provides deltas to RFC4960 and is organized in a time based
way. The issues are listed in the order they were brought up. way. The issues are listed in the order they were brought up.
Because some text is changed several times the last delta in the text Because some text is changed several times the last delta in the text
is the one which should be applied. In addition to the delta a is the one which should be applied. In addition to the delta a
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 May 3, 2018. This Internet-Draft will expire on May 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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 19 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 4 3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 4
3.1. Path Error Counter Threshold Handling . . . . . . . . . . 4 3.1. Path Error Counter Threshold Handling . . . . . . . . . . 4
3.2. Upper Layer Protocol Shutdown Request Handling . . . . . 5 3.2. Upper Layer Protocol Shutdown Request Handling . . . . . 5
3.3. Registration of New Chunk Types . . . . . . . . . . . . . 5 3.3. Registration of New Chunk Types . . . . . . . . . . . . . 6
3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 6 3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 7
3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 7 3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 8
3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 8 3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 9
3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 9 3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 10
3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 10 3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 11
3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 11 3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 12
3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 17 3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 18
3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 18 3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 19
3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 18 3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 19
3.13. HEARTBEAT ACK and the association error counter . . . . . 19 3.13. HEARTBEAT ACK and the association error counter . . . . . 20
3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 21 3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 22
3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 22 3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 23
3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 22 3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 23
3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 23 3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 24
3.18. Only One Packet after Retransmission Timeout . . . . . . 24 3.18. Only One Packet after Retransmission Timeout . . . . . . 25
3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 25 3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 26
3.20. Zero Window Probing and Unreachable Primary Path . . . . 26 3.20. Zero Window Probing and Unreachable Primary Path . . . . 27
3.21. Normative Language in Section 10 . . . . . . . . . . . . 27 3.21. Normative Language in Section 10 . . . . . . . . . . . . 28
3.22. Increase of partial_bytes_acked in Congestion Avoidance . 31 3.22. Increase of partial_bytes_acked in Congestion Avoidance . 32
3.23. Inconsistency in Notifications Handling . . . . . . . . . 32 3.23. Inconsistency in Notifications Handling . . . . . . . . . 33
3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 36 3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 37
3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 38 3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 39
3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 39 3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 40
3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 41 3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 42
3.28. Window Updates After Receiver Window Opens Up . . . . . . 42 3.28. Window Updates After Receiver Window Opens Up . . . . . . 43
3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 43 3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 44
3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 45 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 46
3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 46 3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 47
3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 47 3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 48
3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 49 3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 50
3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 49 3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 50
3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 50 3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 51
3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 52 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 53
3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 53 3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 54
3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 54 3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 55
3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 55 3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 56
3.40. Updating References Regarding ECN . . . . . . . . . . . . 57 3.40. Updating References Regarding ECN . . . . . . . . . . . . 58
3.41. Host Name Address Parameter Deprecated . . . . . . . . . 59 3.41. Host Name Address Parameter Deprecated . . . . . . . . . 60
3.42. Conflicting Text Regarding the Supported Address Types 3.42. Conflicting Text Regarding the Supported Address Types
Parameter . . . . . . . . . . . . . . . . . . . . . . . . 62 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 63
3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 63 3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 64
3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 65 3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 66
3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 67 3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 68
3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 70 3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 71
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 81
5. Security Considerations . . . . . . . . . . . . . . . . . . . 80 3.48. Handling of SSN Wrap Arounds . . . . . . . . . . . . . . 82
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80 3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 83
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84
7.1. Normative References . . . . . . . . . . . . . . . . . . 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 84
7.2. Informative References . . . . . . . . . . . . . . . . . 81 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.1. Normative References . . . . . . . . . . . . . . . . . . 84
7.2. Informative References . . . . . . . . . . . . . . . . . 85
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86
1. Introduction 1. Introduction
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
the publishing of this document for [RFC4960] specifying the Stream the publishing of this document for [RFC4960] specifying the Stream
Control Transmission Protocol (SCTP). These defects may be of an Control Transmission Protocol (SCTP). These defects may be of an
editorial or technical nature. This document may be thought of as a editorial or technical nature. This document may be thought of as a
companion document to be used in the implementation of SCTP to companion document to be used in the implementation of SCTP to
clarify errors in the original SCTP document. clarify errors in the original SCTP document.
skipping to change at page 4, line 8 skipping to change at page 4, line 10
Note that when reading this document one must use care to assure that Note that when reading this document one must use care to assure that
a field or item is not updated further on within the document. Each a field or item is not updated further on within the document. Each
section should be applied in sequence to the original [RFC4960] since section should be applied in sequence to the original [RFC4960] since
this document is a historical record of the sequential changes that this document is a historical record of the sequential changes that
have been found necessary at various inter-op events and through have been found necessary at various inter-op events and through
discussion on the list. discussion on the list.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Corrections to RFC 4960 3. Corrections to RFC 4960
3.1. Path Error Counter Threshold Handling 3.1. Path Error Counter Threshold Handling
3.1.1. Description of the Problem 3.1.1. Description of the Problem
The handling of the 'Path.Max.Retrans' parameter is described in The handling of the 'Path.Max.Retrans' parameter is described in
Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way. Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way.
Whereas Section 8.2 describes that a path is marked inactive when the Whereas Section 8.2 describes that a path is marked inactive when the
skipping to change at page 80, line 24 skipping to change at page 81, line 24
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);
} }
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.1. Description of the Problem
The Gap Ack Blocks in the SACK chunk are intended to be isolated.
However, this is not mentioned with normative text.
3.47.2. Text Changes to the Document
---------
Old text: (Section 3.3.4)
---------
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack
Block acknowledges a subsequence of TSNs received following a break
in the sequence of received TSNs. By definition, all TSNs
acknowledged by Gap Ack Blocks are greater than the value of the
Cumulative TSN Ack.
---------
New text: (Section 3.3.4)
---------
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack
Block acknowledges a subsequence of TSNs received following a break
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 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
Cumulative TSN Ack.
---------
Old text: (Section 3.3.4)
---------
Gap Ack Blocks:
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.
---------
New text: (Section 3.3.4)
---------
Gap Ack Blocks:
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 SHOULD be isolated. That means that
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.
3.47.3. Solution Description
Normative text describing the intended usage of Gap Ack Blocks has
been added.
3.48. Handling of SSN Wrap Arounds
3.48.1. Description of the Problem
The Stream Sequence Numbers (SSN) is used for perserving the ordering
of user messages within each SCTP stream. The SSN is limited to 16
bits. Therefore, multiple wrap arounds of the SSN might happen
within the current send window. To allow the receiver to deliver
ordered user messages in the correct sequence, the sender should
limit the number of user messages per stream.
3.48.2. Text Changes to the Document
---------
Old text: (Section 6.1)
---------
Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
1 above the beginning TSN of the current send window.
---------
New text: (Section 6.1)
---------
Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
1 above the beginning TSN of the current send window.
Note: For each stream, the data sender SHOULD NOT have more than 2**16-1
ordered user messages in the current send window.
3.48.3. Solution Description
The data sender is required to limit the number of ordered user
messages within the current send window.
3.49. Update RFC 2119 Boilerplate
3.49.1. Description of the Problem
The text to be used to refer to the [RFC2119] terms has been updated
by [RFC8174].
3.49.2. Text Changes to the Document
---------
Old text: (Section 2)
---------
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
---------
New text: (Section 2)
---------
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3.49.3. Solution Description
The text has been updated to the one specified in [RFC8174].
4. IANA Considerations 4. IANA Considerations
This document does not require any actions from IANA. This document does not require any actions from IANA.
5. Security Considerations 5. Security Considerations
This document does not add any security considerations to those given This document does not add any security considerations to those given
in [RFC4960]. in [RFC4960].
6. Acknowledgments 6. Acknowledgments
skipping to change at page 82, line 27 skipping to change at page 86, line 27
[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-
IMMEDIATELY Extension for the Stream Control Transmission IMMEDIATELY Extension for the Stream Control Transmission
Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013,
<https://www.rfc-editor.org/info/rfc7053>. <https://www.rfc-editor.org/info/rfc7053>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Netflix, Inc. Netflix, Inc.
Chapin, SC 29036 Chapin, SC 29036
United States United States
Email: randall@lakerest.net Email: randall@lakerest.net
Michael Tuexen Michael Tuexen
 End of changes. 9 change blocks. 
57 lines changed or deleted 197 lines changed or added

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