draft-ietf-tsvwg-rfc4960-errata-00.txt   draft-ietf-tsvwg-rfc4960-errata-01.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: March 3, 2017 Muenster Univ. of Appl. Sciences Expires: May 3, 2017 Muenster Univ. of Appl. Sciences
M. Proshin M. Proshin
Ericsson Ericsson
August 30, 2016 October 30, 2016
RFC 4960 Errata and Issues RFC 4960 Errata and Issues
draft-ietf-tsvwg-rfc4960-errata-00.txt draft-ietf-tsvwg-rfc4960-errata-01.txt
Abstract Abstract
This document is a compilation of issues found since the publication This document is a compilation of issues found since the publication
of RFC4960 in September 2007 based on experience with implementing, of RFC4960 in September 2007 based on experience with implementing,
testing, and using SCTP along with the suggested fixes. This testing, and using SCTP along with the suggested fixes. This
document provides deltas to RFC4960 and is organized in a time based document provides deltas to RFC4960 and is organized in a time based
way. The issues are listed in the order they were brought up. way. The issues are listed in the order they were brought up.
Because some text is changed several times the last delta in the text Because some text is changed several times the last delta in the text
is the one which should be applied. In addition to the delta a is the one which should be applied. In addition to the delta a
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 3, 2017. This Internet-Draft will expire on May 3, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 3 3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 3
3.1. Path Error Counter Threshold Handling . . . . . . . . . . 3 3.1. Path Error Counter Threshold Handling . . . . . . . . . . 3
3.2. Upper Layer Protocol Shutdown Request Handling . . . . . 4 3.2. Upper Layer Protocol Shutdown Request Handling . . . . . 4
3.3. Registration of New Chunk Types . . . . . . . . . . . . . 5 3.3. Registration of New Chunk Types . . . . . . . . . . . . . 5
3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 6 3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 6
3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 7 3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 7
3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 8 3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 8
3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 9 3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 9
3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 10 3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 10
3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 11 3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 11
3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 15 3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 17
3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 15 3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 18
3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 16 3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 18
3.13. HEARTBEAT ACK and the association error counter . . . . . 17 3.13. HEARTBEAT ACK and the association error counter . . . . . 19
3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 19 3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 21
3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 20 3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 22
3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 20 3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 22
3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 21 3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 23
3.18. Only One Packet after Retransmission Timeout . . . . . . 22 3.18. Only One Packet after Retransmission Timeout . . . . . . 24
3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 23 3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 25
3.20. Zero Window Probing and Unreachable Primary Path . . . . 24 3.20. Zero Window Probing and Unreachable Primary Path . . . . 26
3.21. Normative Language in Section 10 . . . . . . . . . . . . 25 3.21. Normative Language in Section 10 . . . . . . . . . . . . 27
3.22. Increase of partial_bytes_acked in Congestion Avoidance . 29 3.22. Increase of partial_bytes_acked in Congestion Avoidance . 31
3.23. Inconsistency in Notifications Handling . . . . . . . . . 30 3.23. Inconsistency in Notifications Handling . . . . . . . . . 32
3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 34 3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 36
3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 36 3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 38
3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 37 3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 39
3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 39 3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 41
3.28. Window Updates After Receiver Window Opens Up . . . . . . 40 3.28. Window Updates After Receiver Window Opens Up . . . . . . 42
3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 41 3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 43
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 45
5. Security Considerations . . . . . . . . . . . . . . . . . . . 43 3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 46
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 5. Security Considerations . . . . . . . . . . . . . . . . . . . 47
7.1. Normative References . . . . . . . . . . . . . . . . . . 43 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
7.2. Informative References . . . . . . . . . . . . . . . . . 43 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.1. Normative References . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 7.2. Informative References . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
the publishing of this document for [RFC4960] specifying the Stream the publishing of this document for [RFC4960] specifying the Stream
Control Transmission Protocol (SCTP). These defects may be of an Control Transmission Protocol (SCTP). These defects may be of an
editorial or technical nature. This document may be thought of as a editorial or technical nature. This document may be thought of as a
companion document to be used in the implementation of SCTP to companion document to be used in the implementation of SCTP to
clarify errors in the original SCTP document. clarify errors in the original SCTP document.
skipping to change at page 15, line 20 skipping to change at page 15, line 20
Problem",, or "Packet Too Big". Problem",, or "Packet Too Big".
--------- ---------
New text: (Appendix C) New text: (Appendix C)
--------- ---------
ICMP2) An implementation MAY ignore all ICMPv6 messages where the ICMP2) An implementation MAY ignore all ICMPv6 messages where the
type field is not "Destination Unreachable", "Parameter type field is not "Destination Unreachable", "Parameter
Problem", or "Packet Too Big". Problem", or "Packet Too Big".
---------
Old text: (Section 5.4)
---------
2) For the receiver of the COOKIE ECHO, the only CONFIRMED address
is the one to which the INIT-ACK was sent.
---------
New text: (Section 5.4)
---------
2) For the receiver of the COOKIE ECHO, the only CONFIRMED address
is the one to which the INIT ACK was sent.
---------
Old text: (Section 5.1.6, Figure 4)
---------
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
---------
New text: (Section 5.1.6, Figure 4)
---------
COOKIE ECHO [Cookie_Z] ------\
(Start T1-cookie timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE ACK
/
(Cancel T1-cookie timer, <---/
Enter ESTABLISHED state)
---------
Old text: (Section 5.2.5)
---------
5.2.5. Handle Duplicate COOKIE-ACK.
---------
New text: (Section 5.2.5)
---------
5.2.5. Handle Duplicate COOKIE ACK.
---------
Old text: (Section 8.3)
---------
By default, an SCTP endpoint SHOULD monitor the reachability of the
idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport
address(es). HEARTBEAT sending MAY begin upon reaching the
ESTABLISHED state and is discontinued after sending either SHUTDOWN
or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a
HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state
(INIT sender) or the ESTABLISHED state (INIT receiver), up until
reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-
ACK-SENT state (SHUTDOWN receiver).
---------
New text: (Section 8.3)
---------
By default, an SCTP endpoint SHOULD monitor the reachability of the
idle destination transport address(es) of its peer by sending a
HEARTBEAT chunk periodically to the destination transport
address(es). HEARTBEAT sending MAY begin upon reaching the
ESTABLISHED state and is discontinued after sending either SHUTDOWN
or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a
HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state
(INIT sender) or the ESTABLISHED state (INIT receiver), up until
reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-
ACK-SENT state (SHUTDOWN receiver).
3.9.3. Solution Description 3.9.3. Solution Description
Typos fixed. Typos fixed.
3.10. CRC32c Sample Code 3.10. CRC32c Sample Code
3.10.1. Description of the Problem 3.10.1. Description of the Problem
The CRC32c computation is described in Appendix B of [RFC4960]. The CRC32c computation is described in Appendix B of [RFC4960].
However, the corresponding sample code and its explanation appears at However, the corresponding sample code and its explanation appears at
skipping to change at page 43, line 16 skipping to change at page 45, line 16
The SACK transmission policy is left implementation dependent but it The SACK transmission policy is left implementation dependent but it
is specified to not vary the destination address of a packet is specified to not vary the destination address of a packet
containing a SACK chunk unless there are reasons for it as it may containing a SACK chunk unless there are reasons for it as it may
negatively impact RTT measurement. negatively impact RTT measurement.
A confusing statement that prescribes to follow the rule for A confusing statement that prescribes to follow the rule for
transmittal of reply chunks when the endpoint is bundling DATA chunks transmittal of reply chunks when the endpoint is bundling DATA chunks
together with the reply chunk is removed. together with the reply chunk is removed.
3.30. Outstanding Data, Flightsize and Data In Flight Key Terms
3.30.1. Description of the Problem
[RFC4960] uses outstanding data, flightsize and data in flight key
terms in formulas and statements but their definitions are not
provided in Section 1.3. Furthermore, outstanding data does not
include DATA chunks which are classified as lost but which has not
been retransmitted yet and there is a paragraph in Section 6.1 of
[RFC4960] where this statement is broken.
3.30.2. Text Changes to the Document
---------
Old text: (Section 1.3)
---------
o Congestion window (cwnd): An SCTP variable that limits the data,
in number of bytes, a sender can send to a particular destination
transport address before receiving an acknowledgement.
...
o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated
DATA chunk) that has been sent by the endpoint but for which it
has not yet received an acknowledgement.
---------
New text: (Section 1.3)
---------
o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated
DATA chunk) that has been sent by the endpoint but for which it
has not yet received an acknowledgement.
o Outstanding data (or Data outstanding or Data in flight): The
total amount of the DATA chunks associated with outstanding TSNs.
A retransmitted DATA chunk is counted once in outstanding data.
A DATA chunk which is classified as lost but which has not been
retransmitted yet is not in outstanding data.
o Flightsize: The amount of bytes of outstanding data to a
particular destination transport address at any given time.
o Congestion window (cwnd): An SCTP variable that limits outstanding
data, in number of bytes, a sender can send to a particular
destination transport address before receiving an acknowledgement.
---------
Old text: (Section 6.1)
---------
C) When the time comes for the sender to transmit, before sending new
DATA chunks, the sender MUST first transmit any outstanding DATA
chunks that are marked for retransmission (limited by the current
cwnd).
---------
New text: (Section 6.1)
---------
C) When the time comes for the sender to transmit, before sending new
DATA chunks, the sender MUST first transmit any DATA chunks that
are marked for retransmission (limited by the current cwnd).
3.30.3. Solution Description
Now Section 1.3, Key Terms, includes explanations of outstanding
data, data in flight and flightsize key terms. Section 6.1 is
corrected to properly use the outstanding data term.
3.31. CWND Degradation due to Max.Burst
3.31.1. Description of the Problem
Some implementations were experiencing a degradation of cwnd because
of the Max.Burst limit. This was due to misinterpretation of the
suggestion in [RFC4960], Section 6.1, on how to use the Max.Burst
parameter when calculating the number of packets to transmit.
3.31.2. Text Changes to the Document
---------
Old text: (Section 6.1)
---------
D) When the time comes for the sender to transmit new DATA chunks,
the protocol parameter Max.Burst SHOULD be used to limit the
number of packets sent. The limit MAY be applied by adjusting
cwnd as follows:
if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +
Max.Burst*MTU
Or it MAY be applied by strictly limiting the number of packets
emitted by the output routine.
---------
New text: (Section 6.1)
---------
D) When the time comes for the sender to transmit new DATA chunks,
the protocol parameter Max.Burst SHOULD be used to limit the
number of packets sent. The limit MAY be applied by adjusting
cwnd as follows:
if((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize + Max.Burst*MTU
Or it MAY be applied by strictly limiting the number of packets
emitted by the output routine. When calculating the number of
packets to transmit and particularly using the formula above,
cwnd SHOULD NOT be changed.
3.31.3. Solution Description
The new text clarifies that cwnd should not be changed when appling
the Max.Burst limit. This mitigates packet bursts related to the
reception of SACK chunks, but not bursts related to an application
sending a burst of user messages.
4. IANA Considerations 4. IANA Considerations
This document does not require any actions from IANA. This document does not require any actions from IANA.
5. Security Considerations 5. Security Considerations
This document does not add any security considerations to those given This document does not add any security considerations to those given
in [RFC4960]. in [RFC4960].
6. Acknowledgments 6. Acknowledgments
 End of changes. 7 change blocks. 
32 lines changed or deleted 231 lines changed or added

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