draft-ietf-tsvwg-rfc4960-errata-04.txt   draft-ietf-tsvwg-rfc4960-errata-05.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 17, 2018 Muenster Univ. of Appl. Sciences Expires: September 6, 2018 Muenster Univ. of Appl. Sciences
M. Proshin M. Proshin
Ericsson Ericsson
November 13, 2017 March 5, 2018
RFC 4960 Errata and Issues RFC 4960 Errata and Issues
draft-ietf-tsvwg-rfc4960-errata-04.txt draft-ietf-tsvwg-rfc4960-errata-05.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
way. The issues are listed in the order they were brought up. ordered way. The issues are listed in the order they were brought
Because some text is changed several times the last delta in the text up. Because some text is changed several times the last delta in the
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
description of the problem and the details of the solution are also description of the problem and the details of the solution are also
provided. provided.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 17, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 18 3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 19
3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 19 3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 20
3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 19 3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 20
3.13. HEARTBEAT ACK and the association error counter . . . . . 20 3.13. HEARTBEAT ACK and the association error counter . . . . . 21
3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 22 3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 23
3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 23 3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 24
3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 23 3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 24
3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 24 3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 25
3.18. Only One Packet after Retransmission Timeout . . . . . . 25 3.18. Only One Packet after Retransmission Timeout . . . . . . 26
3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 26 3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 27
3.20. Zero Window Probing and Unreachable Primary Path . . . . 27 3.20. Zero Window Probing and Unreachable Primary Path . . . . 28
3.21. Normative Language in Section 10 . . . . . . . . . . . . 28 3.21. Normative Language in Section 10 . . . . . . . . . . . . 29
3.22. Increase of partial_bytes_acked in Congestion Avoidance . 32 3.22. Increase of partial_bytes_acked in Congestion Avoidance . 33
3.23. Inconsistency in Notifications Handling . . . . . . . . . 33 3.23. Inconsistency in Notifications Handling . . . . . . . . . 34
3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 37 3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 38
3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 39 3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 40
3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 40 3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 41
3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 42 3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 43
3.28. Window Updates After Receiver Window Opens Up . . . . . . 43 3.28. Window Updates After Receiver Window Opens Up . . . . . . 44
3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 44 3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 45
3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 46 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 47
3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 47 3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 48
3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 48 3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 49
3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 50 3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 51
3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 50 3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 51
3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 51 3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 52
3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 53 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 54
3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 54 3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 55
3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 55 3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 56
3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 56 3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 57
3.40. Updating References Regarding ECN . . . . . . . . . . . . 58 3.40. Updating References Regarding ECN . . . . . . . . . . . . 59
3.41. Host Name Address Parameter Deprecated . . . . . . . . . 60 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 . . . . . . . . . . . . . . . . . . . . . . . . 63 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 64
3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 64 3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 65
3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 66 3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 67
3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 68 3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 69
3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 71 3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 72
3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 81 3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 82
3.48. Handling of SSN Wrap Arounds . . . . . . . . . . . . . . 82 3.48. Handling of SSN Wrap Arounds . . . . . . . . . . . . . . 83
3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 83 3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 84
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 85
5. Security Considerations . . . . . . . . . . . . . . . . . . . 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 85
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.1. Normative References . . . . . . . . . . . . . . . . . . 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 85
7.2. Informative References . . . . . . . . . . . . . . . . . 85 7.2. Informative References . . . . . . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
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 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.
This document provides a history of the changes that will be compiled This document provides a history of the changes that will be compiled
into a BIS document for [RFC4960]. It is structured similar to into a BIS document for [RFC4960]. It is structured similar to
[RFC4460]. [RFC4460].
Each error will be detailed within this document in the form of: Each error will be detailed within this document in the form of:
skipping to change at page 5, line 21 skipping to change at page 5, line 21
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.
--------- ---------
New text: (Section 8.3) New text: (Section 8.3)
--------- ---------
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.
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
skipping to change at page 6, line 16 skipping to change at page 6, line 16
--------- ---------
Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT
send a SHUTDOWN in response to a ULP request, and should discard send a SHUTDOWN in response to a ULP request, and should discard
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 NOT Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST
send a SHUTDOWN in response to a ULP request, and should discard ignore ULP shutdown requests, but MUST continue responding
subsequent ULP shutdown requests. to SHUTDOWN chunks from its peer.
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
Section 14.1 of [RFC4960] should deal with new chunk types, however, Section 14.1 of [RFC4960] should deal with new chunk types, however,
the text refers to parameter types. the text refers to parameter types.
This issue was reported as an Errata for [RFC4960] with Errata ID This issue was reported as an Errata for [RFC4960] with Errata ID
skipping to change at page 7, line 17 skipping to change at page 7, line 17
The assignment of new chunk parameter type codes is done through an The assignment of new chunk parameter type codes is done through an
IETF Consensus action, as defined in [RFC2434]. Documentation of the IETF Consensus action, as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information: chunk parameter MUST contain the following information:
--------- ---------
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 [RFC2434]. Documentation of the IETF Consensus action, as defined in [RFC5226]. Documentation of the
chunk type MUST contain the following information: chunk type MUST contain the following information:
3.3.3. Solution Description 3.3.3. Solution Description
Refer to chunk types as intended. Refer to chunk types as intended.
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
skipping to change at page 10, line 17 skipping to change at page 10, line 17
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 retransmissions to all the retransmissions to its peer (this includes retransmissions to all the
destination transport addresses of the peer if it is multi-homed), destination transport addresses of the peer if it is multi-homed),
including unacknowledged HEARTBEAT chunks. including unacknowledged HEARTBEAT chunks.
--------- ---------
New text: (Section 8.1) New text: (Section 8.1)
--------- ---------
An endpoint shall 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 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 shall 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 currently is 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).
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
skipping to change at page 12, line 39 skipping to change at page 12, line 39
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 catched. While processing [RFC4960] some typos were not caught.
3.9.2. Text Changes to the Document 3.9.2. Text Changes to the Document
--------- ---------
Old text: (Section 1.6) Old 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.
skipping to change at page 14, line 36 skipping to change at page 14, line 36
Endpoint A Endpoint Z Endpoint A Endpoint Z
{App sends 3 messages; strm 0} {App sends 3 messages; strm 0}
DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed) DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)
(Start T3-rtx timer) (Start T3-rtx timer)
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,
/ Strt=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)
--------- ---------
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,
skipping to change at page 15, line 22 skipping to change at page 15, line 22
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 Path MTU. to the current PMTU.
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1)
--------- ---------
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) 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])
--------- ---------
Old text: (Section 10.1)
---------
M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id,
[,destination transport address,]
protocol parameter list)
---------
New text: (Section 10.1)
---------
M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id,
[destination transport address,]
protocol parameter list)
---------
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)
--------- ---------
skipping to change at page 16, line 35 skipping to change at page 17, line 19
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 path MTU discovery. information as defined for PMTU discovery.
--------- ---------
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)
skipping to change at page 19, line 14 skipping to change at page 20, line 14
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 detecting from SACK but the should be reset to 0 after packet loss detection from SACK but the
same is missed for T3-rtx timer expiration. same is missed for T3-rtx timer expiration.
3.11.2. Text Changes to the Document 3.11.2. Text Changes to the Document
--------- ---------
Old text: (Section 7.2.3) Old 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
--------- ---------
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
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.
skipping to change at page 20, line 25 skipping to change at page 21, line 25
reset partial_bytes_acked to (partial_bytes_acked - cwnd). reset partial_bytes_acked to (partial_bytes_acked - cwnd).
--------- ---------
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 MTU. to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU.
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
skipping to change at page 21, line 16 skipping to change at page 22, line 16
--------- ---------
The counter shall be reset each time a DATA chunk sent to that peer The counter shall be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT
ACK is received from the peer endpoint. ACK is received from the peer endpoint.
--------- ---------
New text: (Section 8.1) New text: (Section 8.1)
--------- ---------
The counter shall be reset each time a DATA chunk sent to that peer The counter SHOULD 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.
--------- ---------
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
skipping to change at page 21, line 42 skipping to change at page 22, line 42
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 must also clear the HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the
association overall error count as well (as defined in Section 8.1). association overall error count as well (as defined in Section 8.1).
--------- ---------
New text: (Section 8.3) New 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
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).
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
[RFC4960] clearly describes where to retransmit data that is timed [RFC4960] clearly describes where to retransmit data that is timed
out when the peer is multi-homed but the same is not stated for fast out when the peer is multi-homed but the same is not stated for fast
retransmissions. retransmissions.
3.14.2. Text Changes to the Document 3.14.2. Text Changes to the Document
--------- ---------
Old text: (Section 6.4) Old text: (Section 6.4)
--------- ---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
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.
--------- ---------
New text: (Section 6.4) New text: (Section 6.4)
--------- ---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
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 retransmissions to the same destination transport address where the
original data was sent to. If the primary path has been changed and original data was sent to. If the primary path has been changed and the
original data was sent there before the fast retransmit, the original data was sent there before the fast retransmit, the
implementation MAY send it to the new primary path. implementation MAY send it to the new primary path.
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
skipping to change at page 23, line 35 skipping to change at page 24, line 35
Retransmit is being performed, the sender SHOULD ignore the value Retransmit is being performed, the sender SHOULD ignore the value
of cwnd and SHOULD NOT delay retransmission for this single of cwnd and SHOULD NOT delay retransmission for this single
packet. packet.
--------- ---------
New text: (Section 7.2.4) New text: (Section 7.2.4)
--------- ---------
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 path MTU 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.
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.
skipping to change at page 24, line 27 skipping to change at page 25, line 27
o The initial value of ssthresh MAY be arbitrarily high (for o The initial value of ssthresh MAY be arbitrarily high (for
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.,
to the size of the largest possible advertised window). the size of the largest possible advertised window).
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
The Path Verification procedure of [RFC4960] prescribes that any The Path Verification procedure of [RFC4960] prescribes that any
address passed to the sender of the INIT by its upper layer is address passed to the sender of the INIT by its upper layer is
automatically CONFIRMED. This however is unclear if only addresses automatically CONFIRMED. This, however, is unclear if only addresses
in the request to initiate association establishment are considered in the request to initiate association establishment are considered
or any addresses provided by the upper layer in any requests (e.g. in or any addresses provided by the upper layer in any requests (e.g. in
'Set Primary'). 'Set Primary').
3.17.2. Text Changes to the Document 3.17.2. Text Changes to the Document
--------- ---------
Old text: (Section 5.4) Old text: (Section 5.4)
--------- ---------
1) Any address passed to the sender of the INIT by its upper layer 1) Any address passed to the sender of the INIT by its upper layer
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 is layer in the request to initialize an association are
automatically considered to be CONFIRMED. automatically considered to be CONFIRMED.
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
skipping to change at page 27, line 34 skipping to change at page 28, line 34
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.
3.19.3. Solution Description 3.19.3. Solution Description
The new text requires sending INIT ACK to the destination address The new text requires sending INIT ACK to a destination address that
that is passed by the upper layer and reported in the incoming INIT. is passed by the upper layer and reported in the incoming INIT. If
If the source address of the INIT fulfills it then sending the INIT the source address of the INIT meets these conditions, sending the
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
Section 6.1 of [RFC4960] states that when sending zero window probes, Section 6.1 of [RFC4960] states that when sending zero window probes,
SCTP should neither increment the association counter nor increment SCTP should neither increment the association counter nor increment
the destination address error counter if it continues to receive new the destination address error counter if it continues to receive new
packets from the peer. But receiving new packets from the peer does packets from the peer. However, the reception of new packets from
not guarantee peer's accessibility and, if the destination address the peer does not guarantee the peer's reachability and, if the
becomes unreachable during zero window probing, SCTP cannot get a destination address becomes unreachable during zero window probing,
changed rwnd until it switches the destination address for probes. SCTP cannot get an updated rwnd until it switches the destination
address for probes.
3.20.2. Text Changes to the Document 3.20.2. Text Changes to the Document
--------- ---------
Old text: (Section 6.1) Old text: (Section 6.1)
--------- ---------
If the sender continues to receive new packets from the receiver If the sender continues to receive new packets from the receiver
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 MAY destination transport address. This is because the receiver MAY
keep its window closed for an indefinite time. Refer to Section keep its window closed for an indefinite time. Refer to Section
6.2 on the receiver behavior when it advertises a zero window. 6.2 on the receiver behavior when it advertises a zero window.
--------- ---------
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 MAY destination transport address. This is because the receiver could
keep its window closed for an indefinite time. Refer to Section keep its window closed for an indefinite time. Section 6.2 describes
6.2 on the receiver behavior when it advertises a zero window. the receiver behavior when it advertises a zero window.
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 normative language such as Section 10 of [RFC4960] is informative and, therefore, normative
MUST and MAY cannot be used there. However, there are several places language such as MUST and MAY cannot be used there. However, there
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) Send E) Send
Format: SEND(association id, buffer address, byte count [,context] Format: SEND(association id, buffer address, byte count [,context]
skipping to change at page 31, line 21 skipping to change at page 32, line 21
that no more deliveries will be received for this Stream Sequence that no more deliveries will be received for this Stream Sequence
Number. Number.
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1)
--------- ---------
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])
... ...
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) 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])
... ...
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.
skipping to change at page 33, line 22 skipping to change at page 34, line 22
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 cahnge is based on the change described in Section 3.6. 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 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 34, line 32 skipping to change at page 35, line 32
(and thus the association enters the CLOSED state). In addition, the (and thus the association enters the CLOSED state). In addition, the
endpoint MAY report the failure to the upper layer and optionally endpoint MAY 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.
--------- ---------
New text: (Section 8.1) New text: (Section 8.1)
--------- ---------
An endpoint shall 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
transfer. Unacknowledged HEARTBEAT chunks observed on paths transfer. Unacknowledged HEARTBEAT chunks observed on paths
different from the path currently used for data transfer shall 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 currently is used for to association closure even if the path which currently is used for
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 shall 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]. The following changes are based on [RFC4960].
--------- ---------
Old text: (Section 8.2) Old text: (Section 8.2)
skipping to change at page 35, line 26 skipping to change at page 36, line 26
address of the last chunk sent. However, this ambiguity does not address of the last chunk sent. However, this ambiguity does not
seem to bear any significant consequence to SCTP behavior. If this seem to bear any significant consequence to SCTP behavior. If this
ambiguity is undesirable, the transmitter may choose not to clear the ambiguity is undesirable, the transmitter may choose not to clear the
error counter if the last chunk sent was a retransmission. error counter if the last chunk sent was a retransmission.
--------- ---------
New text: (Section 8.2) New 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 SHOULD
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), and SHOULD the DATA chunk was last sent (or HEARTBEAT was sent), and SHOULD
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
should 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.
--------- ---------
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
counter. counter.
--------- ---------
New text: (Section 8.3) New text: (Section 8.3)
--------- ---------
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.
--------- ---------
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
HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the
association overall error count as well (as defined in Section 8.1). association overall error count as well (as defined in Section 8.1).
--------- ---------
New text: (Section 8.3) New 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 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).
--------- ---------
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).
--------- ---------
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).
--------- ---------
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).
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
skipping to change at page 39, line 29 skipping to change at page 40, line 29
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
must discard it while processing the chunks of the packet. It is must discard it while processing the chunks of the packet. It is
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 do not perform any prescreening of chunks in the received chunk and not to perform any prescreening of chunks in the received
packet so the receiver must only discard a chunk causing discard and packet. Thus, by discarding one chunk the receiver also causes
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'.
--------- ---------
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 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. Furthermore, we require
chunk MUST have a zero Verification Tag. Furthermore, we require that the receiver of an INIT chunk MUST enforce these rules by
that the receiver of an INIT chunk MUST enforce these rules by silently discarding an arriving packet with an INIT chunk that is
silently discarding an arriving packet with an INIT chunk that is bundled with other chunks or has a non-zero verification tag and
bundled with other chunks or has a non-zero verification tag and contains an INIT-chunk.
contains an INIT-chunk.
--------- ---------
New text: (Section 11.3) New 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 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. Furthermore, we require The receiver of an INIT chunk MUST silently discard the INIT chunk and all
that the receiver of an INIT chunk MUST enforce these rules by further chunks if the INIT chunk is bundled with other chunks or the packet
silently discarding the INIT chunk and all further chunks if the INIT has a non-zero verification tag.
chunk is bundled with other chunks or the packet has a non-zero
verification tag.
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
RTT if the sender has cwnd or more bytes of outstanding data to the RTT if the sender has cwnd or more bytes of data outstanding to the
corresponding address in the Congestion Avoidance phase. However, corresponding address in the Congestion Avoidance phase. However,
this is described without normative language. Moreover, this is described without normative language. Moreover,
Section 7.2.2 includes an algorithm how an implementation can achieve Section 7.2.2 includes an algorithm how an implementation can achieve
it but this algorithm is underspecified and actually allows this but this algorithm is underspecified and actually allows
increasing cwnd by more than 1*MTU per RTT. increasing cwnd by more than 1*MTU per RTT.
3.26.2. Text Changes to the Document 3.26.2. Text Changes to the Document
--------- ---------
Old text: (Section 7.2.2) Old text: (Section 7.2.2)
--------- ---------
-------- When cwnd is greater than ssthresh, cwnd should be incremented by
When cwnd is greater than ssthresh, cwnd should be incremented by 1*MTU per RTT if the sender has cwnd or more bytes of data
1*MTU per RTT if the sender has cwnd or more bytes of data outstanding for the corresponding transport address.
outstanding for the corresponding transport address.
--------- ---------
New text: (Section 7.2.2) New text: (Section 7.2.2)
--------- ---------
-------- When cwnd is greater than ssthresh, cwnd SHOULD be incremented by
When cwnd is greater than ssthresh, cwnd should be incremented by 1*MTU per RTT if the sender has cwnd or more bytes of data
1*MTU per RTT if the sender has cwnd or more bytes of data outstanding for the corresponding transport address. The basic
outstanding for the corresponding transport address. The basic 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.
--------- ---------
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.
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), increase cwnd by MTU, and was greater than or equal to cwnd), increase cwnd by MTU, and
reset partial_bytes_acked to (partial_bytes_acked - cwnd). reset partial_bytes_acked to (partial_bytes_acked - cwnd).
--------- ---------
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.
o When partial_bytes_acked is greater than cwnd and before the o When partial_bytes_acked is greater than cwnd and before the
arrival of the SACK the sender had less bytes of data outstanding arrival of the SACK the sender had less than cwnd bytes of data outstanding
than cwnd (i.e., before arrival of the SACK, flightsize was less (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 MTU. to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU.
3.26.3. Solution Description 3.26.3. Solution Description
The basic guidelines for incrementing cwnd during 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
3.27.1. Description of the Problem 3.27.1. Description of the Problem
[RFC4960] prescribes to adjust cwnd per RTO if the endpoint does not [RFC4960] prescribes to adjust cwnd per RTO if the endpoint does not
transmit data on a given transport address. In addition to that, it transmit data on a given transport address. In addition to that, it
prescribes to set cwnd to the initial value after a sufficiently long prescribes to set cwnd to the initial value after a sufficiently long
idle period. The latter is excessive. Moreover, it is unclear what idle period. The latter is excessive. Moreover, it is unclear what
is a sufficiently long idle period. is a sufficiently long idle period.
[RFC4960] doesn't specify the handling of ssthresh in the idle case. [RFC4960] doesn't specify the handling of ssthresh in the idle case.
If ssthres is reduced due to a packet loss, ssthresh is never If ssthresh is reduced due to a packet loss, ssthresh is never
recovered. So traffic can end up in Congestion Avoidance all the recovered. So traffic can end up in Congestion Avoidance all the
time, resulting in a low sending rate and bad performance. The time, resulting in a low sending rate and bad performance. The
problem is even more serious for SCTP because in a multi-homed SCTP problem is even more serious for SCTP because in a multi-homed SCTP
association traffic switch back to the previously failed primary path association traffic that switches back to the previously failed
will also lead to the situation where traffic ends up in Congestion primary path will also lead to the situation where traffic ends up in
Avoidance. Congestion Avoidance.
3.27.2. Text Changes to the Document 3.27.2. Text Changes to the Document
--------- ---------
Old text: (Section 7.2.1) Old text: (Section 7.2.1)
--------- ---------
o The initial cwnd before DATA transmission or after a sufficiently o The initial cwnd before DATA transmission or after a sufficiently
long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 long idle period MUST be set to min(4*MTU, max (2*MTU, 4380
bytes)). bytes)).
skipping to change at page 43, line 34 skipping to change at page 44, line 34
--------- ---------
o When the endpoint does not transmit data on a given transport o When 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) per RTO. max(cwnd/2, 4*MTU) per RTO.
--------- ---------
New text: (Section 7.2.1) New text: (Section 7.2.1)
--------- ---------
o When the endpoint does not transmit data on a given transport o When 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) per RTO. At the first cwnd adjustment, the max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the
ssthresh of the transport address should be adjusted to the cwnd. ssthresh of the transport address SHOULD be adjusted to the cwnd.
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 refresh ssthresh after the idle period. When The text is updated to refresh ssthresh after the idle period. When
the idle period is detected, the cwnd value is stored to the ssthresh the idle period is detected, the cwnd value is stored to the ssthresh
value. value.
skipping to change at page 44, line 33 skipping to change at page 45, line 33
--------- ---------
New text: (Section 6.2) New text: (Section 6.2)
--------- ---------
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 receiver MUST avoid the window even if no new data is received. The receiver MUST avoid
sending large burst of window updates. sending large bursts of window updates.
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 45, line 45 skipping to change at page 46, line 45
--------- ---------
An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK,
HEARTBEAT ACK, etc.) in response to control chunks to the same HEARTBEAT ACK, etc.) in response to control chunks to the same
destination transport address from which it received the control destination transport address from which it received the control
chunk to which it is replying. chunk to which it is replying.
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 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.
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
skipping to change at page 46, line 23 skipping to change at page 47, line 23
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.
3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms
3.30.1. Description of the Problem 3.30.1. Description of the Problem
[RFC4960] uses outstanding data, flightsize and data in flight key [RFC4960] uses outstanding data, flightsize and data in flight key
terms in formulas and statements but their definitions are not terms in formulas and statements but their definitions are not
provided in Section 1.3. Furthermore, outstanding data does not provided in Section 1.3. Furthermore, outstanding data does not
include DATA chunks which are classified as lost but which has not include DATA chunks which are classified as lost but which have not
been retransmitted yet and there is a paragraph in Section 6.1 of been retransmitted yet and there is a paragraph in Section 6.1 of
[RFC4960] where this statement is broken. [RFC4960] where this statement is broken.
3.30.2. Text Changes to the Document 3.30.2. Text Changes to the Document
--------- ---------
Old text: (Section 1.3) Old text: (Section 1.3)
--------- ---------
o Congestion window (cwnd): An SCTP variable that limits the data, o Congestion window (cwnd): An SCTP variable that limits the data,
skipping to change at page 48, line 26 skipping to change at page 49, line 26
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. emitted by the output routine.
--------- ---------
New text: (Section 6.1) New text: (Section 6.1)
--------- ---------
D) When the time comes for the sender to transmit new DATA chunks, D) When the time comes for the sender to transmit new DATA chunks,
the protocol parameter Max.Burst SHOULD be used to limit the the protocol parameter Max.Burst SHOULD be used to limit the
number of packets sent. The limit MAY be applied by adjusting number of packets sent. The limit MAY be applied by adjusting
cwnd 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. cwnd SHOULD NOT be changed permanently.
3.31.3. Solution Description 3.31.3. Solution Description
The new text clarifies that cwnd should not be changed when appling The new text clarifies that cwnd should not be changed when 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
skipping to change at page 50, line 37 skipping to change at page 51, line 37
"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 in the same DATA chunk. The endpoint may bundle the ERROR chunk in the same
packet as the SACK as long as the ERROR follows the SACK. packet as the SACK as long as the ERROR follows the SACK.
--------- ---------
New text: (Section 6.5) New text: (Section 6.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
shall 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.
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
skipping to change at page 51, line 45 skipping to change at page 52, line 45
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
in packets hitting different queues on the path and therefore the in packets hitting different queues on the path and, therefore, the
congestion control should be initialized when the DSCP is changed by congestion control should be initialized when the DSCP is changed by
the upper layer. This is not described in [RFC4960]. the upper layer. This is not described in [RFC4960].
3.35.2. Text Changes to the Document 3.35.2. Text Changes to the Document
--------- ---------
New text: (Section 7.2.5) New text: (Section 7.2.5)
--------- ---------
SCTP implementations MAY allow an application to configure the SCTP implementations MAY allow an application to configure the
skipping to change at page 54, line 39 skipping to change at page 55, line 39
--------- ---------
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.
3.36.3. Solution Description 3.36.3. Solution Description
The text has been changed to not limit the processing of ICMPv4 The text has been changed to not limit the processing of ICMPv4
packets with type "Destination Unreachable" by rewording the third packets with type "Destination Unreachable" by rewording the third
rule. Furthermore, remove in the ninth rule the limitation to rule. Furthermore, remove the limitation to ICMPv6 in the ninth
ICMPv6. 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
skipping to change at page 55, line 28 skipping to change at page 56, line 28
ICMP8) If the ICMP type is "Destination Unreachable", the ICMP8) 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.
3.37.3. Solution Description 3.37.3. Solution Description
Text has been added allowing the SCTP to notify the application in Text has been added allowing SCTP to notify the application in case
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
window only when it is being fully utilized. Since SCTP uses DATA window only when it is being fully utilized. Since SCTP uses DATA
chunks and does not use the congestion window to fragment user chunks and does not use the congestion window to fragment user
messages, this requires that some overbooking of the congestion messages, this requires that some overbooking of the congestion
window is allowed. window is allowed.
skipping to change at page 56, line 35 skipping to change at page 57, line 35
--------- ---------
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.
3.38.3. Solution Description 3.38.3. Solution Description
Text was added that 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
chunk to be transmitted. Even in this case, zero window probing has chunk to be transmitted. Even in this case, zero window probing has
to be performed to avoid deadlocks. to be performed to avoid deadlocks.
skipping to change at page 58, line 10 skipping to change at page 59, line 10
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
[I-D.ietf-tsvwg-ecn-experimentation]. This needs to be reflected [RFC8311]. This needs to be reflected when referring to ECN.
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 ECN as specified in [RFC3168] updated by [RFC8311] describes a proposed
[I-D.ietf-tsvwg-ecn-experimentation] describes a proposed extension extension to IP that details a method to become aware of congestion
to IP that details a method to become aware of congestion outside outside of datagram loss.
of datagram loss.
--------- ---------
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 [I-D.ietf-tsvwg-ecn-experimentation] In general, [RFC3168] updated by [RFC8311] SHOULD be followed with the
should be followed with the following exceptions. following exceptions.
--------- ---------
Old text: (Appendix A) Old text: (Appendix A)
--------- ---------
[RFC3168] details negotiation of ECN during the SYN and SYN-ACK [RFC3168] details negotiation of ECN during the SYN and SYN-ACK
stages of a TCP connection. stages of a TCP connection.
--------- ---------
New text: (Appendix A) New text: (Appendix A)
--------- ---------
[RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] details [RFC3168] updated by [RFC8311] details negotiation of ECN during the
negotiation of ECN during the SYN and SYN-ACK stages of a TCP SYN and SYN-ACK stages of a TCP connection.
connection.
--------- ---------
Old text: (Appendix A) Old text: (Appendix A)
--------- ---------
[RFC3168] details a specific bit for a receiver to send back in its [RFC3168] details a specific bit for a receiver to send back in its
TCP acknowledgements to notify the sender of the Congestion TCP acknowledgements to notify the sender of the Congestion
Experienced (CE) bit having arrived from the network. Experienced (CE) bit having arrived from the network.
--------- ---------
New text: (Appendix A) New text: (Appendix A)
--------- ---------
[RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] [RFC3168] updated by [RFC8311] details a specific bit for a receiver
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) Old text: (Appendix A)
--------- ---------
[RFC3168] details a specific bit for a sender to send in the header [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 of its next outbound TCP segment to indicate to its peer that it has
reduced its congestion window. reduced its congestion window.
--------- ---------
New text: (Appendix A) New text: (Appendix A)
--------- ---------
[RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] [RFC3168] updated by [RFC8311] details a specific bit for a sender
details a specific bit for a sender to send in the header to send in the header of its next outbound TCP segment to indicate to
of its next outbound TCP segment to indicate to its peer that it has its peer that it has reduced its congestion window.
reduced its congestion window.
3.40.3. Solution Description 3.40.3. Solution Description
References to [I-D.ietf-tsvwg-ecn-experimentation] have been added. References to [RFC8311] have been added.
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
[RFC4960] defines three types of address parameters to be used with [RFC4960] defines three types of address parameters to be used with
INIT and INIT ACK chunks: INIT and INIT ACK chunks:
1. IPv4 Address parameters. 1. IPv4 Address parameters.
2. IPv6 Address parameters. 2. IPv6 Address parameters.
skipping to change at page 60, line 39 skipping to change at page 61, line 28
Address parameter. Moreover, the sender of the INIT MUST NOT combine Address parameter. Moreover, the sender of the INIT MUST NOT combine
any other address types with the Host Name Address in the INIT. The any other address types with the Host Name Address in the INIT. The
receiver of INIT MUST ignore any other address types if the Host Name receiver of INIT MUST ignore any other address types if the Host Name
Address parameter is present in the received INIT chunk. Address parameter is present in the received INIT chunk.
--------- ---------
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 an 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.
--------- ---------
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
skipping to change at page 61, line 43 skipping to change at page 62, line 31
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 an 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.
--------- ---------
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
skipping to change at page 62, line 48 skipping to change at page 63, line 36
to its peer. The ABORT shall be sent to the source IP address to 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.
--------- ---------
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.
--------- ---------
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.
skipping to change at page 63, line 29 skipping to change at page 64, line 17
address of the INIT, the endpoint MAY silently discard the INIT. address of the INIT, the endpoint MAY silently discard the INIT.
This last option will not protect against the attack against the DNS. This last option will not protect against the attack against the DNS.
--------- ---------
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
an MAY include an Error Cause indicating an Unresolvable Address. and MAY include an Error Cause indicating an Unresolvable Address.
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
Supported Address Types, there is conflicting text in Section 5.1.2 Supported Address Types, there is conflicting text in Section 5.1.2
of [RFC4960]. It is stated that the association MUST be aborted and of [RFC4960]. It is stated that the association MUST be aborted and
also that the association SHOULD be established and there SHOULD NOT also that the association SHOULD be established and there SHOULD NOT
be any error indication. be any error indication.
3.42.2. Text Changes to the Document 3.42.2. Text Changes to the Document
--------- ---------
Old text: (Section 5.1.2) Old text: (Section 5.1.2)
--------- ---------
-------- The sender of INIT may include a 'Supported Address Types' parameter
The sender of INIT may include a 'Supported Address Types' parameter in the INIT to indicate what types of address are acceptable. When
in the INIT to indicate what types of address are acceptable. When this parameter is present, the receiver of INIT (initiate) MUST
this parameter is present, the receiver of INIT (initiate) MUST either use one of the address types indicated in the Supported
either use one of the address types indicated in the Supported Address Types parameter when responding to the INIT, or abort the
Address Types parameter when responding to the INIT, or abort the association with an "Unresolvable Address" error cause if it is
association with an "Unresolvable Address" error cause if it is unwilling or incapable of using any of the address types indicated by
unwilling or incapable of using any of the address types indicated by 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' parameter
The sender of INIT may include a 'Supported Address Types' parameter in the INIT to indicate what types of addresses are acceptable.
in the INIT to indicate what types of address are acceptable.
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
skipping to change at page 65, line 5 skipping to change at page 66, line 5
The assignment of new chunk parameter type codes is done through an The assignment of new chunk parameter type codes is done through an
IETF Consensus action, as defined in [RFC2434]. Documentation of the IETF Consensus action, as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information: chunk parameter MUST contain the following information:
a) A long and short name for the new chunk type. a) A long and short name for the new chunk type.
b) A detailed description of the structure of the chunk, which MUST b) A detailed description of the structure of the chunk, which MUST
conform to the basic structure defined in Section 3.2. conform to the basic structure defined in Section 3.2.
c) A detailed definition and description of intended use of each c) A detailed definition and description of the intended use of each
field within the chunk, including the chunk flags if any. field within the chunk, including the chunk flags if any.
d) A detailed procedural description of the use of the new chunk type d) A detailed procedural description of the use of the new chunk type
within the operation of the protocol. 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.
--------- ---------
New text: (Section 14.1) New text: (Section 14.1)
skipping to change at page 65, line 30 skipping to change at page 66, line 30
The assignment of new chunk type codes is done through an IETF Review The assignment of new chunk type codes is done through an IETF Review
action, as defined in [RFC5226]. Documentation of a new chunk MUST action, as defined in [RFC5226]. Documentation of a new chunk MUST
contain the following information: contain the following information:
a) A long and short name for the new chunk type; a) A long and short name for the new chunk type;
b) A detailed description of the structure of the chunk, which MUST b) A detailed description of the structure of the chunk, which MUST
conform to the basic structure defined in Section 3.2 of conform to the basic structure defined in Section 3.2 of
[RFC4960]; [RFC4960];
c) A detailed definition and description of intended use of each c) A detailed definition and description of the intended use of each
field within the chunk, including the chunk flags if any. field within the chunk, including the chunk flags if any.
Defined chunk flags will be used as initial entries in the chunk Defined chunk flags will be used as initial entries in the chunk
flags table for the new chunk type; flags table for the new chunk type;
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.
skipping to change at page 66, line 13 skipping to change at page 67, line 13
action, as defined in [RFC5226]. Documentation of the chunk flags action, as defined in [RFC5226]. 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.
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.
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. [RFC6096] was integrated.
skipping to change at page 68, line 7 skipping to change at page 69, line 7
existing TCP registration. existing TCP registration.
o Concrete intent to use a port SHOULD precede port registration. o Concrete intent to use a port SHOULD precede port registration.
For example, existing TCP ports SHOULD NOT be registered in For example, existing TCP ports SHOULD NOT be registered in
advance of any intent to use those ports for SCTP. advance of any intent to use those ports for SCTP.
--------- ---------
New text: (Section 14.5) New text: (Section 14.5)
--------- ---------
SCTP services may 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].
3.44.3. Solution Description 3.44.3. Solution Description
skipping to change at page 69, line 28 skipping to change at page 70, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier | | Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ User Data (seq n of Stream S) / / User Data (seq n of Stream S) /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
--------- ---------
New text: (Append to Section 6.1) New text: (Append to Section 6.1)
--------- ---------
skipping to change at page 70, line 23 skipping to change at page 71, line 23
Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. Note: The SHUTDOWN chunk does not contain Gap Ack Block fields.
Therefore, the endpoint should use a SACK instead of the SHUTDOWN Therefore, the endpoint should use a SACK instead of the SHUTDOWN
chunk to acknowledge DATA chunks received out of order. chunk to acknowledge DATA chunks received out of order.
--------- ---------
New text: (Section 6.2) New text: (Section 6.2)
--------- ---------
Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. Note: The SHUTDOWN chunk does not contain Gap Ack Block fields.
Therefore, the endpoint should use a SACK instead of the SHUTDOWN Therefore, the endpoint SHOULD use a SACK instead of the SHUTDOWN
chunk to acknowledge DATA chunks received out of order. chunk to acknowledge DATA chunks received out of order.
Upon receipt of an SCTP packet containing a DATA chunk with the I bit 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 set, the receiver SHOULD NOT delay the sending of the corresponding
SACK chunk, i.e., the receiver SHOULD immediately respond with the SACK chunk, i.e., the receiver SHOULD immediately respond with the
corresponding SACK chunk. corresponding SACK chunk.
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1)
--------- ---------
skipping to change at page 71, line 27 skipping to change at page 72, line 27
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 like processors. Therefore, the code is changed to use specific types
uint32_t. like uint32_t.
While there, fix also some syntax errors. While there, fix also some syntax errors.
3.46.2. Text Changes to the Document 3.46.2. Text Changes to the Document
--------- ---------
Old text: (Appendix B) Old text: (Appendix B)
--------- ---------
/* Example of the crc table file */ /* Example of the crc table file */
#ifndef __crc32cr_table_h__ #ifndef __crc32cr_table_h__
skipping to change at page 77, line 24 skipping to change at page 78, line 24
uint32_t rb; uint32_t rb;
rb = reflect_32(index); rb = reflect_32(index);
for (i = 0; i < 8; i++) { for (i = 0; i < 8; i++) {
if (rb & 0x80000000UL) if (rb & 0x80000000UL)
rb = (rb << 1) ^ (uint32_t)CRC32C_POLY; rb = (rb << 1) ^ (uint32_t)CRC32C_POLY;
else else
rb <<= 1; rb <<= 1;
} }
return (reflect_32 (rb)); return (reflect_32(rb));
} }
int int
main (void) main (void)
{ {
int i; int i;
printf("\nGenerating CRC-32c table file <%s>\n", printf("\nGenerating CRC-32c table file <%s>\n",
OUTPUT_FILE); OUTPUT_FILE);
if ((tf = fopen (OUTPUT_FILE, "w")) == NULL) { if ((tf = fopen(OUTPUT_FILE, "w")) == NULL) {
printf ("Unable to open %s\n", OUTPUT_FILE); printf ("Unable to open %s\n", OUTPUT_FILE);
exit (1); exit (1);
} }
fprintf(tf, "#ifndef __crc32cr_h__\n"); fprintf(tf, "#ifndef __crc32cr_h__\n");
fprintf(tf, "#define __crc32cr_h__\n\n"); fprintf(tf, "#define __crc32cr_h__\n\n");
fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n", fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n",
(uint32_t)CRC32C_POLY); (uint32_t)CRC32C_POLY);
fprintf(tf, fprintf(tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf(tf, "\nuint32_t crc_c[256] =\n{\n"); fprintf(tf, "\nuint32_t crc_c[256] =\n{\n");
skipping to change at page 79, line 49 skipping to change at page 80, line 49
} }
--------- ---------
New text: (Appendix B) New text: (Appendix B)
--------- ---------
/* Example of crc insertion */ /* Example of crc insertion */
#include "crc32cr.h" #include "crc32cr.h"
unsigned long uint32_t
generate_crc32c(unsigned char *buffer, unsigned int length) generate_crc32c(unsigned char *buffer, unsigned int length)
{ {
unsigned int i; unsigned int i;
uint32_t crc32 = 0xffffffffUL; uint32_t crc32 = 0xffffffffUL;
uint32_t result; uint32_t result;
uint8_t byte0, byte1, byte2, byte3; uint8_t byte0, byte1, byte2, byte3;
for (i = 0; i < length; i++) { for (i = 0; i < length; i++) {
CRC32C(crc32, buffer[i]); CRC32C(crc32, buffer[i]);
} }
skipping to change at page 82, line 48 skipping to change at page 83, line 48
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
The Stream Sequence Numbers (SSN) is used for perserving the ordering The Stream Sequence Number (SSN) is used for preserving the ordering
of user messages within each SCTP stream. The SSN is limited to 16 of user messages within each SCTP stream. The SSN is limited to 16
bits. Therefore, multiple wrap arounds of the SSN might happen bits. Therefore, multiple wrap arounds of the SSN might happen
within the current send window. To allow the receiver to deliver within the current send window. To allow the receiver to deliver
ordered user messages in the correct sequence, the sender should ordered user messages in the correct sequence, the sender should
limit the number of user messages per stream. limit the number of user messages per stream.
3.48.2. Text Changes to the Document 3.48.2. Text Changes to the Document
--------- ---------
Old text: (Section 6.1) Old text: (Section 6.1)
skipping to change at page 84, line 28 skipping to change at page 85, line 28
"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.
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].
4. IANA Considerations 4. IANA Considerations
This document does not require any actions from IANA. Section 3.44 of this document updates the port number registry for
SCTP to be consistent with [RFC6335]. IANA is requested to review
Section 3.44.
5. Security Considerations 5. Security Considerations
This document does not add any security considerations to those given This document does not add any security considerations to those given
in [RFC4960]. in [RFC4960].
6. Acknowledgments 6. Acknowledgments
The authors wish to thank Pontus Andersson, Eric W. Biederman, The authors wish to thank Pontus Andersson, Eric W. Biederman,
Cedric Bonnet, Lionel Morand, Jeff Morriss, Karen E. E. Nielsen, Cedric Bonnet, Gorry Fairhurst, Peter Lei, Lionel Morand, Jeff
Tom Petch, Julien Pourtet, and Michael Welzl for their invaluable Morriss, Karen E. E. Nielsen, Tom Petch, Kacheong Poon, Julien
comments. Pourtet, Irene Ruengeler, Michael Welzl, and Qiaobing Xie for their
invaluable comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-tsvwg-ecn-experimentation]
Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", draft-ietf-tsvwg-ecn-
experimentation-07 (work in progress), October 2017.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000,
<https://www.rfc-editor.org/info/rfc2960>. <https://www.rfc-editor.org/info/rfc2960>.
skipping to change at page 86, line 31 skipping to change at page 87, line 31
[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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.
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. 152 change blocks. 
376 lines changed or deleted 384 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/