draft-ietf-tsvwg-sctpimpguide-07.txt   draft-ietf-tsvwg-sctpimpguide-08.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: April 1, 2003 L. Ong Expires: August 27, 2003 L. Ong
Ciena Systems Ciena Systems
I. Arias-Rodriguez I. Arias-Rodriguez
Nokia Research Center Nokia Research Center
K. Poon K. Poon
Sun Microsysystems, Inc. Consultant
P. Conrad P. Conrad
Temple University Temple University
A. Caro A. Caro
Department of Computer & University of Delaware
Information Sciences University of
Delaware
M. Tuexen M. Tuexen
Siemens AG February 26, 2003
October 1, 2002
Stream Control Transmission Protocol (SCTP) Implementers Guide Stream Control Transmission Protocol (SCTP) Implementer's Guide
draft-ietf-tsvwg-sctpimpguide-07.txt draft-ietf-tsvwg-sctpimpguide-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 1, 2003. This Internet-Draft will expire on August 27, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
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 the Stream Control Transmission the publishing of this document for the Stream Control Transmission
Protocol (SCTP) RFC2960 [3]. These defects may be of an editorial or Protocol (SCTP) RFC2960 [5]. These defects may be of an editorial or
technical nature. This document may be thought of as a companion technical nature. This document may be thought of as a companion
document to be used in the implementation of SCTP to clarify errors document to be used in the implementation of SCTP to clarify errors
in the original SCTP document. in the original SCTP document.
This document updates RFC2960 [3] and text within this document This document updates RFC2960 [5] and text within this document
supersedes the text found in RFC2960 [3]. supersedes the text found in RFC2960 [5].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Corrections to RFC2960 . . . . . . . . . . . . . . . . . . 7 2. Corrections to RFC2960 . . . . . . . . . . . . . . . . . . 6
2.1 Incorrect error type during chunk processing. . . . . . . 7 2.1 Incorrect error type during chunk processing. . . . . . . 6
2.1.1 Description of the problem . . . . . . . . . . . . . . . . 7 2.1.1 Description of the problem . . . . . . . . . . . . . . . . 6
2.1.2 Text changes to the document . . . . . . . . . . . . . . . 7 2.1.2 Text changes to the document . . . . . . . . . . . . . . . 6
2.1.3 Solution description . . . . . . . . . . . . . . . . . . . 7 2.1.3 Solution description . . . . . . . . . . . . . . . . . . . 6
2.2 Parameter processing issue . . . . . . . . . . . . . . . . 7 2.2 Parameter processing issue . . . . . . . . . . . . . . . . 6
2.2.1 Description of the problem . . . . . . . . . . . . . . . . 7 2.2.1 Description of the problem . . . . . . . . . . . . . . . . 6
2.2.2 Text changes to the document . . . . . . . . . . . . . . . 8 2.2.2 Text changes to the document . . . . . . . . . . . . . . . 7
2.2.3 Solution description . . . . . . . . . . . . . . . . . . . 8 2.2.3 Solution description . . . . . . . . . . . . . . . . . . . 7
2.3 Padding issues . . . . . . . . . . . . . . . . . . . . . . 8 2.3 Padding issues . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Description of the problem . . . . . . . . . . . . . . . . 8 2.3.1 Description of the problem . . . . . . . . . . . . . . . . 7
2.3.2 Text changes to the document . . . . . . . . . . . . . . . 8 2.3.2 Text changes to the document . . . . . . . . . . . . . . . 7
2.3.3 Solution description . . . . . . . . . . . . . . . . . . . 10 2.3.3 Solution description . . . . . . . . . . . . . . . . . . . 9
2.4 Parameter types across all chunk types . . . . . . . . . . 10 2.4 Parameter types across all chunk types . . . . . . . . . . 9
2.4.1 Description of the problem . . . . . . . . . . . . . . . . 10 2.4.1 Description of the problem . . . . . . . . . . . . . . . . 9
2.4.2 Text changes to the document . . . . . . . . . . . . . . . 10 2.4.2 Text changes to the document . . . . . . . . . . . . . . . 9
2.4.3 Solution description . . . . . . . . . . . . . . . . . . . 11 2.4.3 Solution description . . . . . . . . . . . . . . . . . . . 10
2.5 Stream parameter clarification . . . . . . . . . . . . . . 12 2.5 Stream parameter clarification . . . . . . . . . . . . . . 11
2.5.1 Description of the problem . . . . . . . . . . . . . . . . 12 2.5.1 Description of the problem . . . . . . . . . . . . . . . . 11
2.5.2 Text changes to the document . . . . . . . . . . . . . . . 12 2.5.2 Text changes to the document . . . . . . . . . . . . . . . 11
2.5.3 Solution description . . . . . . . . . . . . . . . . . . . 13 2.5.3 Solution description . . . . . . . . . . . . . . . . . . . 11
2.6 Restarting association security issue . . . . . . . . . . 13 2.6 Restarting association security issue . . . . . . . . . . 12
2.6.1 Description of the problem . . . . . . . . . . . . . . . . 13 2.6.1 Description of the problem . . . . . . . . . . . . . . . . 12
2.6.2 Text changes to the document . . . . . . . . . . . . . . . 13 2.6.2 Text changes to the document . . . . . . . . . . . . . . . 12
2.6.3 Solution description . . . . . . . . . . . . . . . . . . . 17 2.6.3 Solution description . . . . . . . . . . . . . . . . . . . 16
2.7 Implicit ability to exceed cwnd by PMTU-1 bytes . . . . . 17 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes . . . . . 16
2.7.1 Description of the problem . . . . . . . . . . . . . . . . 17 2.7.1 Description of the problem . . . . . . . . . . . . . . . . 16
2.7.2 Text changes to the document . . . . . . . . . . . . . . . 18 2.7.2 Text changes to the document . . . . . . . . . . . . . . . 17
2.7.3 Solution description . . . . . . . . . . . . . . . . . . . 18 2.7.3 Solution description . . . . . . . . . . . . . . . . . . . 17
2.8 Issues with Fast Retransmit . . . . . . . . . . . . . . . 18 2.8 Issues with Fast Retransmit . . . . . . . . . . . . . . . 17
2.8.1 Description of the problem . . . . . . . . . . . . . . . . 18 2.8.1 Description of the problem . . . . . . . . . . . . . . . . 17
2.8.2 Text changes to the document . . . . . . . . . . . . . . . 18 2.8.2 Text changes to the document . . . . . . . . . . . . . . . 17
2.8.3 Solution description . . . . . . . . . . . . . . . . . . . 21 2.8.3 Solution description . . . . . . . . . . . . . . . . . . . 20
2.9 Missing statement about partial_bytes_acked update . . . . 22 2.9 Missing statement about partial_bytes_acked update . . . . 21
2.9.1 Description of the problem . . . . . . . . . . . . . . . . 22 2.9.1 Description of the problem . . . . . . . . . . . . . . . . 21
2.9.2 Text changes to the document . . . . . . . . . . . . . . . 22 2.9.2 Text changes to the document . . . . . . . . . . . . . . . 21
2.9.3 Solution description . . . . . . . . . . . . . . . . . . . 23 2.9.3 Solution description . . . . . . . . . . . . . . . . . . . 22
2.10 Issues with Heartbeating and failure detection . . . . . . 23 2.10 Issues with Heartbeating and failure detection . . . . . . 22
2.10.1 Description of the problem . . . . . . . . . . . . . . . . 23 2.10.1 Description of the problem . . . . . . . . . . . . . . . . 22
2.10.2 Text changes to the document . . . . . . . . . . . . . . . 24 2.10.2 Text changes to the document . . . . . . . . . . . . . . . 22
2.10.3 Solution description . . . . . . . . . . . . . . . . . . . 26 2.10.3 Solution description . . . . . . . . . . . . . . . . . . . 25
2.11 Security interactions with firewalls . . . . . . . . . . . 26 2.11 Security interactions with firewalls . . . . . . . . . . . 25
2.11.1 Description of the problem . . . . . . . . . . . . . . . . 26 2.11.1 Description of the problem . . . . . . . . . . . . . . . . 25
2.11.2 Text changes to the document . . . . . . . . . . . . . . . 26 2.11.2 Text changes to the document . . . . . . . . . . . . . . . 25
2.11.3 Solution description . . . . . . . . . . . . . . . . . . . 28 2.11.3 Solution description . . . . . . . . . . . . . . . . . . . 27
2.12 Shutdown ambiguity . . . . . . . . . . . . . . . . . . . . 28 2.12 Shutdown ambiguity . . . . . . . . . . . . . . . . . . . . 27
2.12.1 Description of the problem . . . . . . . . . . . . . . . . 28 2.12.1 Description of the problem . . . . . . . . . . . . . . . . 27
2.12.2 Text changes to the document . . . . . . . . . . . . . . . 29 2.12.2 Text changes to the document . . . . . . . . . . . . . . . 27
2.12.3 Solution description . . . . . . . . . . . . . . . . . . . 30 2.12.3 Solution description . . . . . . . . . . . . . . . . . . . 29
2.13 Inconsistency in ABORT processing . . . . . . . . . . . . 30 2.13 Inconsistency in ABORT processing . . . . . . . . . . . . 29
2.13.1 Description of the problem . . . . . . . . . . . . . . . . 30 2.13.1 Description of the problem . . . . . . . . . . . . . . . . 29
2.13.2 Text changes to the document . . . . . . . . . . . . . . . 30 2.13.2 Text changes to the document . . . . . . . . . . . . . . . 29
2.13.3 Solution description . . . . . . . . . . . . . . . . . . . 31 2.13.3 Solution description . . . . . . . . . . . . . . . . . . . 30
2.14 Cwnd gated by its full use . . . . . . . . . . . . . . . . 31 2.14 Cwnd gated by its full use . . . . . . . . . . . . . . . . 30
2.14.1 Description of the problem . . . . . . . . . . . . . . . . 32 2.14.1 Description of the problem . . . . . . . . . . . . . . . . 30
2.14.2 Text changes to the document . . . . . . . . . . . . . . . 32 2.14.2 Text changes to the document . . . . . . . . . . . . . . . 31
2.14.3 Solution description . . . . . . . . . . . . . . . . . . . 34 2.14.3 Solution description . . . . . . . . . . . . . . . . . . . 33
2.15 Window probes in SCTP . . . . . . . . . . . . . . . . . . 35 2.15 Window probes in SCTP . . . . . . . . . . . . . . . . . . 33
2.15.1 Description of the problem . . . . . . . . . . . . . . . . 35 2.15.1 Description of the problem . . . . . . . . . . . . . . . . 34
2.15.2 Text changes to the document . . . . . . . . . . . . . . . 35 2.15.2 Text changes to the document . . . . . . . . . . . . . . . 34
2.15.3 Solution description . . . . . . . . . . . . . . . . . . . 36 2.15.3 Solution description . . . . . . . . . . . . . . . . . . . 35
2.16 Fragmentation and Path MTU issues . . . . . . . . . . . . 37 2.16 Fragmentation and Path MTU issues . . . . . . . . . . . . 36
2.16.1 Description of the problem . . . . . . . . . . . . . . . . 37 2.16.1 Description of the problem . . . . . . . . . . . . . . . . 36
2.16.2 Text changes to the document . . . . . . . . . . . . . . . 37 2.16.2 Text changes to the document . . . . . . . . . . . . . . . 36
2.16.3 Solution description . . . . . . . . . . . . . . . . . . . 38 2.16.3 Solution description . . . . . . . . . . . . . . . . . . . 37
2.17 Initial value of the cumulative TSN Ack . . . . . . . . . 38 2.17 Initial value of the cumulative TSN Ack . . . . . . . . . 37
2.17.1 Description of the problem . . . . . . . . . . . . . . . . 38 2.17.1 Description of the problem . . . . . . . . . . . . . . . . 37
2.17.2 Text changes to the document . . . . . . . . . . . . . . . 39 2.17.2 Text changes to the document . . . . . . . . . . . . . . . 37
2.17.3 Solution description . . . . . . . . . . . . . . . . . . . 39 2.17.3 Solution description . . . . . . . . . . . . . . . . . . . 38
2.18 Handling of address parameters within the INIT or INIT-ACK 39 2.18 Handling of address parameters within the INIT or
2.18.1 Description of the problem . . . . . . . . . . . . . . . . 39 INIT-ACK . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.18.2 Text changes to the document . . . . . . . . . . . . . . . 39 2.18.1 Description of the problem . . . . . . . . . . . . . . . . 38
2.18.3 Solution description . . . . . . . . . . . . . . . . . . . 40 2.18.2 Text changes to the document . . . . . . . . . . . . . . . 38
2.18.3 Solution description . . . . . . . . . . . . . . . . . . . 39
2.19 Handling of stream shortages . . . . . . . . . . . . . . . 40 2.19 Handling of stream shortages . . . . . . . . . . . . . . . 40
2.19.1 Description of the problem . . . . . . . . . . . . . . . . 41 2.19.1 Description of the problem . . . . . . . . . . . . . . . . 40
2.19.2 Text changes to the document . . . . . . . . . . . . . . . 41 2.19.2 Text changes to the document . . . . . . . . . . . . . . . 40
2.19.3 Solution description . . . . . . . . . . . . . . . . . . . 42 2.19.3 Solution description . . . . . . . . . . . . . . . . . . . 41
2.20 Indefinite postponement . . . . . . . . . . . . . . . . . 42 2.20 Indefinite postponement . . . . . . . . . . . . . . . . . 41
2.20.1 Description of the problem . . . . . . . . . . . . . . . . 42 2.20.1 Description of the problem . . . . . . . . . . . . . . . . 41
2.20.2 Text changes to the document . . . . . . . . . . . . . . . 42 2.20.2 Text changes to the document . . . . . . . . . . . . . . . 41
2.20.3 Solution description . . . . . . . . . . . . . . . . . . . 43 2.20.3 Solution description . . . . . . . . . . . . . . . . . . . 42
2.21 User initiated abort of an association . . . . . . . . . . 43 2.21 User initiated abort of an association . . . . . . . . . . 42
2.21.1 Description of the problem . . . . . . . . . . . . . . . . 44 2.21.1 Description of the problem . . . . . . . . . . . . . . . . 42
2.21.2 Text changes to the document . . . . . . . . . . . . . . . 44 2.21.2 Text changes to the document . . . . . . . . . . . . . . . 43
2.21.3 Solution description . . . . . . . . . . . . . . . . . . . 49 2.21.3 Solution description . . . . . . . . . . . . . . . . . . . 48
2.22 Handling of invalid Initiate Tag of INIT-ACK . . . . . . . 49 2.22 Handling of invalid Initiate Tag of INIT-ACK . . . . . . . 48
2.22.1 Description of the problem . . . . . . . . . . . . . . . . 49 2.22.1 Description of the problem . . . . . . . . . . . . . . . . 48
2.22.2 Text changes to the document . . . . . . . . . . . . . . . 49 2.22.2 Text changes to the document . . . . . . . . . . . . . . . 48
2.22.3 Solution description . . . . . . . . . . . . . . . . . . . 50 2.22.3 Solution description . . . . . . . . . . . . . . . . . . . 49
2.23 ABORT sending in response to an INIT . . . . . . . . . . . 50 2.23 ABORT sending in response to an INIT . . . . . . . . . . . 49
2.23.1 Description of the problem . . . . . . . . . . . . . . . . 51 2.23.1 Description of the problem . . . . . . . . . . . . . . . . 50
2.23.2 Text changes to the document . . . . . . . . . . . . . . . 51 2.23.2 Text changes to the document . . . . . . . . . . . . . . . 50
2.23.3 Solution description . . . . . . . . . . . . . . . . . . . 51 2.23.3 Solution description . . . . . . . . . . . . . . . . . . . 50
2.24 Stream Sequence Number (SSN) Initialization . . . . . . . 51 2.24 Stream Sequence Number (SSN) Initialization . . . . . . . 50
2.24.1 Description of the problem . . . . . . . . . . . . . . . . 51 2.24.1 Description of the problem . . . . . . . . . . . . . . . . 50
2.24.2 Text changes to the document . . . . . . . . . . . . . . . 52 2.24.2 Text changes to the document . . . . . . . . . . . . . . . 51
2.24.3 Solution description . . . . . . . . . . . . . . . . . . . 52 2.24.3 Solution description . . . . . . . . . . . . . . . . . . . 51
2.25 SACK packet format . . . . . . . . . . . . . . . . . . . . 52 2.25 SACK packet format . . . . . . . . . . . . . . . . . . . . 51
2.25.1 Description of the problem . . . . . . . . . . . . . . . . 52 2.25.1 Description of the problem . . . . . . . . . . . . . . . . 51
2.25.2 Text changes to the document . . . . . . . . . . . . . . . 53 2.25.2 Text changes to the document . . . . . . . . . . . . . . . 52
2.25.3 Solution description . . . . . . . . . . . . . . . . . . . 53 2.25.3 Solution description . . . . . . . . . . . . . . . . . . . 52
2.26 Protocol Violation Error Cause . . . . . . . . . . . . . . 53 2.26 Protocol Violation Error Cause . . . . . . . . . . . . . . 52
2.26.1 Description of the problem . . . . . . . . . . . . . . . . 53 2.26.1 Description of the problem . . . . . . . . . . . . . . . . 52
2.26.2 Text changes to the document . . . . . . . . . . . . . . . 53 2.26.2 Text changes to the document . . . . . . . . . . . . . . . 52
2.26.3 Solution description . . . . . . . . . . . . . . . . . . . 55 2.26.3 Solution description . . . . . . . . . . . . . . . . . . . 54
2.27 Reporting of Unrecognized Parameters . . . . . . . . . . . 55 2.27 Reporting of Unrecognized Parameters . . . . . . . . . . . 54
2.27.1 Description of the problem . . . . . . . . . . . . . . . . 55 2.27.1 Description of the problem . . . . . . . . . . . . . . . . 54
2.27.2 Text changes to the document . . . . . . . . . . . . . . . 56 2.27.2 Text changes to the document . . . . . . . . . . . . . . . 55
2.27.3 Solution description . . . . . . . . . . . . . . . . . . . 57 2.27.3 Solution description . . . . . . . . . . . . . . . . . . . 56
2.28 Handling of IP Address Parameters . . . . . . . . . . . . 57 2.28 Handling of IP Address Parameters . . . . . . . . . . . . 56
2.28.1 Description of the problem . . . . . . . . . . . . . . . . 57 2.28.1 Description of the problem . . . . . . . . . . . . . . . . 56
2.28.2 Text changes to the document . . . . . . . . . . . . . . . 58 2.28.2 Text changes to the document . . . . . . . . . . . . . . . 57
2.28.3 Solution description . . . . . . . . . . . . . . . . . . . 58 2.28.3 Solution description . . . . . . . . . . . . . . . . . . . 57
2.29 Handling of COOKIE ECHO chunks when a TCB exists . . . . 58 2.29 Handling of COOKIE ECHO chunks when a TCB exists . . . . 57
2.29.1 Description of the problem . . . . . . . . . . . . . . . . 58 2.29.1 Description of the problem . . . . . . . . . . . . . . . . 57
2.29.2 Text changes to the document . . . . . . . . . . . . . . . 59 2.29.2 Text changes to the document . . . . . . . . . . . . . . . 58
2.29.3 Solution description . . . . . . . . . . . . . . . . . . . 59 2.29.3 Solution description . . . . . . . . . . . . . . . . . . . 58
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 60 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 59
References . . . . . . . . . . . . . . . . . . . . . . . . 61 References . . . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 60
Full Copyright Statement . . . . . . . . . . . . . . . . . 63 Intellectual Property and Copyright Statements . . . . . . 63
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 the Stream Control Transmission the publishing of this document for the Stream Control Transmission
Protocol (SCTP) RFC2960 [3]. These defects may be of an editorial or Protocol (SCTP) RFC2960 [5]. These defects may be of an editorial or
technical nature. This document may be thought of as a companion technical nature. This document may be thought of as a companion
document to be used in the implementation of SCTP to clarify errors document to be used in the implementation of SCTP to clarify errors
in the original SCTP document. in the original SCTP document.
This document updates RFC2960 and text within this document, where This document updates RFC2960 and text within this document, where
noted, supersedes the text found in RFC2960 [3]. Each error will be noted, supersedes the text found in RFC2960 [5]. Each error will be
detailed within this document in the form of: detailed within this document in the form of:
o The problem description, o The problem description,
o The text quoted from RFC2960 [3], o The text quoted from RFC2960 [5],
o The replacement text, o The replacement text,
o A description of the solution. o A description of the solution.
1.1 Conventions 1.1 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
RFC2119 [2]. RFC2119 [2].
2. Corrections to RFC2960 2. Corrections to RFC2960
2.1 Incorrect error type during chunk processing. 2.1 Incorrect error type during chunk processing.
2.1.1 Description of the problem 2.1.1 Description of the problem
A typo was discovered in RFC2960 [3] that incorrectly specifies an A typo was discovered in RFC2960 [5] that incorrectly specifies an
action to be taken when processing chunks of unknown identity. action to be taken when processing chunks of unknown identity.
2.1.2 Text changes to the document 2.1.2 Text changes to the document
--------- ---------
Old text: (Section 3.2) Old text: (Section 3.2)
--------- ---------
01 - Stop processing this SCTP packet and discard it, do not process 01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized any further chunks within it, and report the unrecognized
skipping to change at page 11, line 4 skipping to change at page 11, line 4
instances of this parameter type may be found within the same instances of this parameter type may be found within the same
chunk. chunk.
e) Each parameter type MUST be unique across all chunks. e) Each parameter type MUST be unique across all chunks.
2.4.3 Solution description 2.4.3 Solution description
By having all parameters unique across all chunk assignments (the By having all parameters unique across all chunk assignments (the
current assignment policy) no ambiguity exists as to what a parameter current assignment policy) no ambiguity exists as to what a parameter
means based on context. The trade off for this is a smaller means based on context. The trade off for this is a smaller
parameter space i.e. 65,536 parameters versus 65,536 * Number-of- parameter space i.e. 65,536 parameters versus 65,536 *
chunks. Number-of-chunks.
2.5 Stream parameter clarification 2.5 Stream parameter clarification
2.5.1 Description of the problem 2.5.1 Description of the problem
A problem was found where the specification is unclear on the A problem was found where the specification is unclear on the
legality of an endpoint asking for more stream resources than were legality of an endpoint asking for more stream resources than were
allowed in the MIS value of the INIT. In particular the value in the allowed in the MIS value of the INIT. In particular the value in the
INIT ACK requested in its OS value was larger than the MIS value INIT ACK requested in its OS value was larger than the MIS value
received in the INIT chunk. This behavior is illegal yet it was received in the INIT chunk. This behavior is illegal yet it was
unspecified in RFC2960 [3] unspecified in RFC2960 [5]
2.5.2 Text changes to the document 2.5.2 Text changes to the document
--------- ---------
Old text: (Section 3.3.3) Old text: (Section 3.3.3)
--------- ---------
Number of Outbound Streams (OS): 16 bits (unsigned integer) Number of Outbound Streams (OS): 16 bits (unsigned integer)
Defines the number of outbound streams the sender of this INIT ACK Defines the number of outbound streams the sender of this INIT ACK
skipping to change at page 17, line 34 skipping to change at page 17, line 34
2.7.3 Solution description 2.7.3 Solution description
The text changes make clear the ability to go over the cwnd value by The text changes make clear the ability to go over the cwnd value by
no more than (PMTU-1) bytes. no more than (PMTU-1) bytes.
2.8 Issues with Fast Retransmit 2.8 Issues with Fast Retransmit
2.8.1 Description of the problem 2.8.1 Description of the problem
A problem was found in the current specification of fast retransmit. Several problems were found in the current specification of fast
In particular in a high bandwidth * delay network. The current retransmit. The current wording did not require GAP ACK blocks to be
wording did not require GAP ACK blocks to be sent, even though they sent, even though they are essential to the workings of SCTP's
are essential to the workings of SCTP's congestion control. Also the congestion control. The specification left unclear how to handle the
specification left unclear how to handle the fast retransmit cycle, fast retransmit cycle, having the implementation to wait on the cwnd
having the implementation to wait on the cwnd to retransmit a TSN to retransmit a TSN that was marked for fast retransmit. No limit
that was marked for fast retransmit. Also no limit was placed on how was placed on how many times a TSN could be fast retransmitted. Fast
many times a TSN could be fast retransmitted. Recovery was not specified, causing the congestion window to be
reduced drastically when there are multiple losses in a single RTT.
2.8.2 Text changes to the document 2.8.2 Text changes to the document
--------- ---------
Old text: (Section 6.2) Old text: (Section 6.2)
--------- ---------
Acknowledgments MUST be sent in SACK chunks unless shutdown was Acknowledgments MUST be sent in SACK chunks unless shutdown was
requested by the ULP in which case an endpoint MAY send an requested by the ULP in which case an endpoint MAY send an
acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge
skipping to change at page 18, line 22 skipping to change at page 18, line 23
--------- ---------
New text: (Section 6.2) New text: (Section 6.2)
--------- ---------
Acknowledgments MUST be sent in SACK chunks unless shutdown was Acknowledgments MUST be sent in SACK chunks unless shutdown was
requested by the ULP in which case an endpoint MAY send an requested by the ULP in which case an endpoint MAY send an
acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge
the reception of multiple DATA chunks. See Section 3.3.4 for SACK the reception of multiple DATA chunks. See Section 3.3.4 for SACK
chunk format. In particular, the SCTP endpoint MUST fill in the chunk format. In particular, the SCTP endpoint MUST fill in the
Cumulative TSN Ack field to indicate the latest sequential TSN (of a Cumulative TSN Ack field to indicate the latest sequential TSN (of a
valid DATA chunk) it has received. Any received DATA chunks with TSN valid DATA chunk) it has received. Any received DATA chunks with
greater than the value in the Cumulative TSN Ack field MUST also be TSN greater than the value in the Cumulative TSN Ack field are reported
reported in the Gap Ack Block fields. in the Gap Ack Block fields. The SCTP endpoint MUST report as many
Gap Ack Blocks that can fit in a single SACK chunk limited by the
current path MTU.
--------- ---------
Old text: (Section 7.2.4) Old text: (Section 7.2.4)
--------- ---------
Whenever an endpoint receives a SACK that indicates some TSN(s)
missing, it SHOULD wait for 3 further miss indications (via
subsequent SACK's) on the same TSN(s) before taking action with
regard to Fast Retransmit.
When the TSN(s) is reported as missing in the fourth consecutive When the TSN(s) is reported as missing in the fourth consecutive
SACK, the data sender shall: SACK, the data sender shall:
1) Mark the missing DATA chunk(s) for retransmission, 1) Mark the missing DATA chunk(s) for retransmission,
2) Adjust the ssthresh and cwnd of the destination address(es) to 2) Adjust the ssthresh and cwnd of the destination address(es) to
which the missing DATA chunks were last sent, according to the which the missing DATA chunks were last sent, according to the
formula described in Section 7.2.3. formula described in Section 7.2.3.
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
skipping to change at page 19, line 19 skipping to change at page 19, line 27
consecutive SACK reporting the TSN hole. After reaching 4 and consecutive SACK reporting the TSN hole. After reaching 4 and
starting the fast retransmit procedure, the counter resets to 0. starting the fast retransmit procedure, the counter resets to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size. no adjustment to the congestion control window size.
--------- ---------
New text: (Section 7.2.4) New text: (Section 7.2.4)
--------- ---------
When the TSN(s) is reported as missing in the fourth consecutive Whenever an endpoint receives a SACK that indicates some TSN(s)
SACK, the data sender shall: missing, it SHOULD wait for 3 further miss indications (via
subsequent SACK's) on the same TSN(s) before taking action with
regard to Fast Retransmit.
1) Mark the missing DATA chunk(s) for retransmission as described Miss indications SHOULD follow the HTNA (Highest TSN Newly Acknowledged)
below in M1-M3, algorithm. For each incoming SACK, miss indications are incremented only
for missing TSNs prior to the highest TSN newly acknowledged in the
SACK. A newly acknowledged DATA chunk is one not previously acknowledged
in a SACK. If an endpoint is in Fast Recovery and a SACK arrives that
advances the Cumulative TSN Ack Point, the miss indications are
incremented for all TSNs reported missing in the SACK.
2) Adjust the ssthresh and cwnd of the destination address(es) to When the fourth consecutive miss indication is recieved for a TSN(s), the
which the missing DATA chunks were last sent, according to the data sender shall:
formula described in Section 7.2.3.
1) Mark the DATA chunk(s) with four miss indications for retransmission.
2) If not in Fast Recovery, adjust the ssthresh and cwnd of the
destination address(es) to which the missing DATA chunks were last
sent, according to the formula described in Section 7.2.3.
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
marked for retransmission will fit into a single packet, subject marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address to constraint of the path MTU of the destination transport address
to which the packet is being sent. Call this value K. Retransmit to which the packet is being sent. Call this value K. Retransmit
those K DATA chunks in a single packet. When a Fast Retransmit is those K DATA chunks in a single packet. When a Fast Retransmit is
being performed the sender SHOULD ignore the value of cwnd and being performed the sender SHOULD ignore the value of cwnd and
SHOULD NOT delay retransmission. SHOULD NOT delay retransmission for this single packet.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest 4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that retransmitting the first outstanding DATA chunk sent to that
address. address.
5) Mark the DATA chunk(s) as being fast retransmitted and thus 5) Mark the DATA chunk(s) as being fast retransmitted and thus
ineligible for a subsequent fast retransmit. Those TSNs marked ineligible for a subsequent fast retransmit. Those TSNs marked
for retransmission due to the Fast Retransmit algorithm that for retransmission due to the Fast Retransmit algorithm that
did not fit in the sent datagram carrying K other TSNs are also did not fit in the sent datagram carrying K other TSNs are also
marked as ineligible for a subsequent fast retransmit. However, marked as ineligible for a subsequent fast retransmit. However,
as they are marked for retransmission they will be retransmitted as they are marked for retransmission they will be retransmitted
later on as soon as cwnd allows. later on as soon as cwnd allows.
6) If not in Fast Recovery, enter Fast Recovery and mark the highest
outstanding TSN as the Fast Recovery exit point. When a SACK
acknowledges all TSNs up to and including this exit point, Fast
Recovery is exited. While in Fast Recovery, the ssthresh and cwnd
SHOULD NOT change for any destinations.
Note: Before the above adjustments, if the received SACK also Note: Before the above adjustments, if the received SACK also
acknowledges new DATA chunks and advances the Cumulative TSN Ack acknowledges new DATA chunks and advances the Cumulative TSN Ack
Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
must be applied first. must be applied first.
A straightforward implementation of the above is as follows:
M1) Each time a new DATA chunk is transmitted set the
'TSN.Missing.Report' count for that TSN to 0. The
'TSN.Missing.Report' count will be used to determine missing
chunks and when to fast retransmit.
M2) Each time a SACK arrives reporting 'Stray DATA chunk(s)' record
the highest TSN reported as newly acknowledged, call this
value 'HighestTSNinSack'. A newly acknowledged DATA chunk is one
not previously acknowledged in a SACK.
When the SCTP sender of data receives a SACK chunk that
acknowledges, for the first time, the receipt of a DATA chunk,
all the still unacknowledged DATA chunks whose TSN is older than
that newly acknowledged DATA chunk, are qualified as
'Stray DATA chunks'.
M3) Examine all 'Unacknowledged TSN's', if the TSN number of an
'Unacknowledged TSN' is smaller than the 'HighestTSNinSack'
value, increment the 'TSN.Missing.Report' count on that chunk if
it has NOT been fast retransmitted or marked for fast retransmit
already.
M4) If any DATA chunk is found to have a 'TSN.Missing.Report' value
larger than or equal to 4, mark that chunk for retransmission and
start the fast retransmit procedure (steps 2-5 above).
M5) If a T3-rtx timer expires, the 'TSN.Missing.Report' of all
affected TSNs is set to 0.
Because cwnd in SCTP indirectly bounds the number of outstanding
TSN's, the effect of TCP fast-recovery is achieved automatically with
no adjustment to the congestion control window size.
2.8.3 Solution description 2.8.3 Solution description
The effect of the above wording changes are as follows: The effect of the above wording changes are as follows:
o It requires with a MUST the sending of GAP Ack blocks instead of o It requires with a MUST the sending of GAP Ack blocks instead of
the current RFC2960 [3] SHOULD. the current RFC2960 [5] SHOULD.
o It allows a TSN being Fast Retransmitted (FR) to be sent only once o It allows a TSN being Fast Retransmitted (FR) to be sent only once
via FR. via FR.
o It ends the delay in awaiting for the flight size to drop when a o It ends the delay in awaiting for the flight size to drop when a
TSN is identified ready to FR. TSN is identified ready to FR.
o It changes the way chunks are marked during fast retransmit, so o It changes the way chunks are marked during fast retransmit, so
that only new reports are counted (using M1-M4 above). that only new reports are counted.
o It introduces a Fast Recovery period to avoid multiple congestion
window reductions when there are multiple losses in a single RTT
(as shown by Caro et al. [3]).
These changes will effectively allow SCTP to follow a similar model These changes will effectively allow SCTP to follow a similar model
as TCP+SACK in the handling of Fast Retransmit. as TCP+SACK in the handling of Fast Retransmit.
2.9 Missing statement about partial_bytes_acked update 2.9 Missing statement about partial_bytes_acked update
2.9.1 Description of the problem 2.9.1 Description of the problem
SCTP uses four control variables to regulate its transmission rate: SCTP uses four control variables to regulate its transmission rate:
rwnd, cwnd, ssthresh and partial_bytes_acked. Upon detection of rwnd, cwnd, ssthresh and partial_bytes_acked. Upon detection of
skipping to change at page 27, line 33 skipping to change at page 27, line 29
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999. Protocol", RFC 2522, March 1999.
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM "TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999. Computer Communication Review, 29(5), October 1999.
2.11.3 Solution description 2.11.3 Solution description
The above text adding a new subsection to the Security Considerations The above text adding a new subsection to the Security Considerations
section of RFC2960 [3] makes clear that, to make easier the section of RFC2960 [5] makes clear that, to make easier the
interaction with firewalls, an INIT chunk must not be bundled in any interaction with firewalls, an INIT chunk must not be bundled in any
case with any other chunk, being this rule enforced by the packet case with any other chunk, being this rule enforced by the packet
receiver, that will silently discard the packets that do not follow receiver, that will silently discard the packets that do not follow
this rule. this rule.
2.12 Shutdown ambiguity 2.12 Shutdown ambiguity
2.12.1 Description of the problem 2.12.1 Description of the problem
Currently there is an ambiguity between the statements in section 6.2 Currently there is an ambiguity between the statements in section 6.2
skipping to change at page 31, line 13 skipping to change at page 31, line 9
2.14 Cwnd gated by its full use 2.14 Cwnd gated by its full use
2.14.1 Description of the problem 2.14.1 Description of the problem
A problem was found with the current specification of the growth and A problem was found with the current specification of the growth and
decay of cwnd. The cwnd should only be increased if it is being decay of cwnd. The cwnd should only be increased if it is being
fully utilized, and after periods of under utilization, the cwnd fully utilized, and after periods of under utilization, the cwnd
should be decreased. In some sections, the current wording is weak should be decreased. In some sections, the current wording is weak
and is not clearly defined. Also, the current specification and is not clearly defined. Also, the current specification
unnecessarily introduces the need for special case code to ensure unnecessarily introduces the need for special case code to ensure
cwnd degradation. cwnd degradation. Plus, the cwnd should not be increased during Fast
Recovery since a full cwnd during Fast Recovery does not qualify the
cwnd as being fully utilized. Additionally, multiple loss scenarios
in a single window may cause the cwnd to grow more rapidly as the
number of losses in a window increases [3].
2.14.2 Text changes to the document 2.14.2 Text changes to the document
--------- ---------
Old text: (Section 6.1) Old text: (Section 6.1)
--------- ---------
D) Then, the sender can send out as many new DATA chunks as Rule A D) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B above allow. and Rule B above allow.
skipping to change at page 32, line 9 skipping to change at page 32, line 9
incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be
increased by at most the lesser of 1) the total size of the increased by at most the lesser of 1) the total size of the
previously outstanding DATA chunk(s) acknowledged, and 2) the previously outstanding DATA chunk(s) acknowledged, and 2) the
destination's path MTU. This protects against the ACK-Splitting destination's path MTU. This protects against the ACK-Splitting
attack outlined in [SAVAGE99]. attack outlined in [SAVAGE99].
--------- ---------
New text: (Section 7.2.1) New text: (Section 7.2.1)
--------- ---------
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST use
use the slow start algorithm to increase cwnd only if the the slow start algorithm to increase cwnd only if the current
current congestion window is being fully utilized and an congestion window is being fully utilized, an incoming SACK advances
incoming SACK advances the Cumulative TSN Ack Point. Only when the Cumulative TSN Ack Point, and the data sender is not in Fast
these two conditions are met can the cwnd be increased otherwise Recovery. Only when these three conditions are met can the cwnd be
the cwnd MUST not be increased. If these conditions are met then increased otherwise the cwnd MUST not be increased. If these conditions
cwnd MUST be increased by at most the lesser of 1) the total are met then cwnd MUST be increased by at most the lesser of 1) the
size of the previously outstanding DATA chunk(s) acknowledged, total size of the previously outstanding DATA chunk(s) acknowledged,
and 2) the destination's path MTU. This protects against the and 2) the destination's path MTU. This protects against the
ACK-Splitting attack outlined in [SAVAGE99]. ACK-Splitting attack outlined in [SAVAGE99].
--------- ---------
Old text: (Section 7.2.1) Old 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, 2*MTU) per RTO. max(cwnd/2, 2*MTU) per RTO.
--------- ---------
New text: (Section 7.2.1) New text: (Section 7.2.1)
--------- ---------
o When the association does not transmit data on a given transport address o When the association does not transmit data on a given transport address
within an RTO, the cwnd of the transport address MUST be adjusted to within an RTO, the cwnd of the transport address SHOULD be adjusted to
2*MTU. 2*MTU.
--------- ---------
Old text: (Section 7.2.2) Old text: (Section 7.2.2)
--------- ---------
o Same as in the slow start, when the sender does not transmit DATA o Same as in the slow start, when the sender does not transmit DATA
on a given transport address, the cwnd of the transport address on a given transport address, the cwnd of the transport address
should be adjusted to max(cwnd / 2, 2*MTU) per RTO. should be adjusted to max(cwnd / 2, 2*MTU) per RTO.
skipping to change at page 36, line 15 skipping to change at page 36, line 14
2.16 Fragmentation and Path MTU issues 2.16 Fragmentation and Path MTU issues
2.16.1 Description of the problem 2.16.1 Description of the problem
The current wording of the Fragmentation and Reassembly forces an The current wording of the Fragmentation and Reassembly forces an
implementation that supports fragmentation to always fragment. This implementation that supports fragmentation to always fragment. This
prohibits an implementation from offering its users an option to prohibits an implementation from offering its users an option to
disable sends that exceed the SCTP fragmentation point. disable sends that exceed the SCTP fragmentation point.
The restriction in RFC2960 [3] section 6.9 was never meant to The restriction in RFC2960 [5] section 6.9 was never meant to
restrict an implementations API from this behavior. restrict an implementations API from this behavior.
2.16.2 Text changes to the document 2.16.2 Text changes to the document
--------- ---------
Old text: (Section 6.1) Old text: (Section 6.1)
--------- ---------
6.9 Fragmentation and Reassembly 6.9 Fragmentation and Reassembly
skipping to change at page 39, line 43 skipping to change at page 39, line 43
D) When searching for a matching TCB upon reception of an INIT D) When searching for a matching TCB upon reception of an INIT
or INIT-ACK chunk the receiver SHOULD use not only the or INIT-ACK chunk the receiver SHOULD use not only the
source address of the packet (containing the INIT or source address of the packet (containing the INIT or
INIT-ACK) but the receiver SHOULD also use all valid INIT-ACK) but the receiver SHOULD also use all valid
address parameters contained within the chunk. address parameters contained within the chunk.
2.18.3 Solution description 2.18.3 Solution description
This new text clearly specifies to an implementor the need to look This new text clearly specifies to an implementor the need to look
within the INIT or INIT-ACK. Any implementation that does not do within the INIT or INIT ACK. Any implementation that does not do
this, may not be able to establish associations in certain this, may for example not be able to recognize an INIT chunk coming
circumstances. from an already established association that adds new addresses (see
section 2.6), or an incoming INIT ACK chunk sent from a source
address different to the destination address used to send the INIT
chunk.
2.19 Handling of stream shortages 2.19 Handling of stream shortages
2.19.1 Description of the problem 2.19.1 Description of the problem
The current wording in the RFC places the choice of sending an ABORT The current wording in the RFC places the choice of sending an ABORT
upon the SCTP stack when a stream shortage occurs. This decision upon the SCTP stack when a stream shortage occurs. This decision
should really be made by the upper layer not the SCTP stack. should really be made by the upper layer not the SCTP stack.
2.19.2 Text changes to the document 2.19.2 Text changes to the document
skipping to change at page 46, line 25 skipping to change at page 46, line 23
code shall be returned. code shall be returned.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
Optional attributes: Optional attributes:
o cause code - reason of the abort to be passed to the peer. o cause code - reason of the abort to be passed to the peer.
None.
--------- ---------
New text: (Section 10.1) New text: (Section 10.1)
--------- ---------
D) Abort D) Abort
Format: ABORT(association id [, Upper Layer Abort Reason]) Format: ABORT(association id [, Upper Layer Abort Reason])
-> result -> result
Ungracefully closes an association. Any locally queued user data Ungracefully closes an association. Any locally queued user data
skipping to change at page 50, line 30 skipping to change at page 50, line 30
--------- ---------
New text: (Section 8.4) New text: (Section 8.4)
--------- ---------
3) If the packet contains an INIT chunk with a Verification Tag set 3) If the packet contains an INIT chunk with a Verification Tag set
to '0', process it as described in Section 5.1. If, for whatever to '0', process it as described in Section 5.1. If, for whatever
reason, the INIT can not be processed normally and an ABORT has to be reason, the INIT can not be processed normally and an ABORT has to be
sent in response, the Verification Tag of the packet containing the sent in response, the Verification Tag of the packet containing the
ABORT chunk MUST be the Initiate tag of the received INIT chunk ABORT chunk MUST be the Initiate tag of the received INIT chunk
and the T-Bit of the ABORT chunk has to be set to 1 indicating that and the T-Bit of the ABORT chunk has to be set to 1 indicating that
no TCB was destroyed. Otherwise, a TCB was destroyed. Otherwise,
2.23.3 Solution description 2.23.3 Solution description
The new text stated clearly which value of the Verification Tag and The new text stated clearly which value of the Verification Tag and
T-bit have to be used. T-bit have to be used.
2.24 Stream Sequence Number (SSN) Initialization 2.24 Stream Sequence Number (SSN) Initialization
2.24.1 Description of the problem 2.24.1 Description of the problem
skipping to change at page 51, line 22 skipping to change at page 51, line 22
the association is established. Also, when the stream sequence the association is established. Also, when the stream sequence
number reaches the value 65535 the next stream sequence number shall number reaches the value 65535 the next stream sequence number shall
be set to 0. be set to 0.
--------- ---------
New text: (Section 6.5) New text: (Section 6.5)
--------- ---------
The stream sequence number in all the streams MUST start from 0 when The stream sequence number in all the streams MUST start from 0 when
the association is established. Also, when the stream sequence the association is established. Also, when the stream sequence
number reaches the value 65535 the next stream sequence number shall number reaches the value 65535 the next stream sequence number MUST
be set to 0. be set to 0.
2.24.3 Solution description 2.24.3 Solution description
The 'shall' in the text is replaced by a 'MUST' to clearly state the The 'shall' in the text is replaced by a 'MUST' to clearly state the
required behavior. required behavior.
2.25 SACK packet format 2.25 SACK packet format
2.25.1 Description of the problem 2.25.1 Description of the problem
skipping to change at page 53, line 28 skipping to change at page 53, line 28
Cause-specific Information: variable length Cause-specific Information: variable length
This field carries the details of the error condition. This field carries the details of the error condition.
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
Guidelines for the IETF to define new error cause values are Guidelines for the IETF to define new error cause values are
discussed in Section 13.3. discussed in Section 13.3.
--------- ---------
New text: (Section 3.2.10) New text: (Section 3.3.10)
--------- ---------
Cause Code Cause Code
Value Cause Code Value Cause Code
--------- ---------------- --------- ----------------
1 Invalid Stream Identifier 1 Invalid Stream Identifier
2 Missing Mandatory Parameter 2 Missing Mandatory Parameter
3 Stale Cookie Error 3 Stale Cookie Error
4 Out of Resource 4 Out of Resource
5 Unresolvable Address 5 Unresolvable Address
skipping to change at page 54, line 45 skipping to change at page 54, line 45
2.26.3 Solution description 2.26.3 Solution description
An additional error cause which can be used by an endpoint to An additional error cause which can be used by an endpoint to
indicate a protocol violation of the peer has been defined. indicate a protocol violation of the peer has been defined.
2.27 Reporting of Unrecognized Parameters 2.27 Reporting of Unrecognized Parameters
2.27.1 Description of the problem 2.27.1 Description of the problem
It is not stated clearly in RFC2960 [3] how unrecognized parameters It is not stated clearly in RFC2960 [5] how unrecognized parameters
should be reported. Unrecognized parameters in an INIT chunk could should be reported. Unrecognized parameters in an INIT chunk could
be reported in the INIT-ACK chunk or in a separate ERROR chunk which be reported in the INIT-ACK chunk or in a separate ERROR chunk which
can get lost. Unrecognized parameters in an INIT-ACK chunk have to can get lost. Unrecognized parameters in an INIT-ACK chunk have to
be reported in an ERROR-chunk. This can be bundled with the COOKIE- be reported in an ERROR-chunk. This can be bundled with the
ERROR chunk or sent separately. If it is sent separately and COOKIE-ERROR chunk or sent separately. If it is sent separately and
received before the COOKIE-ECHO it will be handled as an OOTB packet received before the COOKIE-ECHO it will be handled as an OOTB packet
resulting in sending out an ABORT chunk. Therefore the association resulting in sending out an ABORT chunk. Therefore the association
would not be established. would not be established.
2.27.2 Text changes to the document 2.27.2 Text changes to the document
Some of the changes given here already include changes suggested in Some of the changes given here already include changes suggested in
section Section 2.2 of this document. section Section 2.2 of this document.
--------- ---------
skipping to change at page 56, line 14 skipping to change at page 56, line 14
--------- ---------
New text: (Note no old text, clarification added in section 3.2) New text: (Note no old text, clarification added in section 3.2)
--------- ---------
3.2.2 Reporting of Unrecognized Parameters 3.2.2 Reporting of Unrecognized Parameters
If the receiver of an INIT chunk detects unrecognized parameters If the receiver of an INIT chunk detects unrecognized parameters
and has to report them according to section 3.2.1 it MUST put and has to report them according to section 3.2.1 it MUST put
the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk
sent in response to the INIT-chunk. sent in response to the INIT-chunk. Note that if the receiver
of the INIT chunk is NOT going to establish an association (e.g.
due to lack of resources) then no report would be sent back.
If the receiver of an INIT-ACK chunk detects unrecognized parameters If the receiver of an INIT-ACK chunk detects unrecognized parameters
and has to report them according to section 3.2.1 it SHOULD bundle and has to report them according to section 3.2.1 it SHOULD bundle
the ERROR chunk containing the 'Unrecognized Parameters' error cause the ERROR chunk containing the 'Unrecognized Parameters' error cause
with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk.
If the receiver of the INIT-ACK can not bundle the COOKIE-ECHO chunk If the receiver of the INIT-ACK can not bundle the COOKIE-ECHO chunk
with the ERROR chunk the ERROR chunk MAY be sent separately but not with the ERROR chunk the ERROR chunk MAY be sent separately but not
before the COOKIE-ACK has been received. before the COOKIE-ACK has been received.
Note: Any time a COOKIE-ECHO is sent in a packet it MUST be the
first chunk.
2.27.3 Solution description 2.27.3 Solution description
The procedure of reporting unrecognized parameters has been described The procedure of reporting unrecognized parameters has been described
clearly. clearly.
2.28 Handling of IP Address Parameters 2.28 Handling of IP Address Parameters
2.28.1 Description of the problem 2.28.1 Description of the problem
It is not stated clearly in RFC2960 [3] how a SCTP endpoint which It is not stated clearly in RFC2960 [5] how a SCTP endpoint which
supports either IPv4 addresses or IPv6 addresses should respond if supports either IPv4 addresses or IPv6 addresses should respond if
IPv4 and IPv6 addresses are presented by the peer in the INIT or IPv4 and IPv6 addresses are presented by the peer in the INIT or
INIT-ACK chunk. INIT-ACK chunk.
2.28.2 Text changes to the document 2.28.2 Text changes to the document
--------- ---------
Old text: (Section 5.1.2) Old text: (Section 5.1.2)
--------- ---------
skipping to change at page 57, line 42 skipping to change at page 57, line 42
2.28.3 Solution description 2.28.3 Solution description
The procedure of handling IP address parameters has been described The procedure of handling IP address parameters has been described
clearly. clearly.
2.29 Handling of COOKIE ECHO chunks when a TCB exists 2.29 Handling of COOKIE ECHO chunks when a TCB exists
2.29.1 Description of the problem 2.29.1 Description of the problem
The description of be behavior in RFC2960 [3] when a COOKIE ECHO The description of be behavior in RFC2960 [5] when a COOKIE ECHO
chunk and a TCB exists could be misunderstood. When a COOKIE ECHO is chunk and a TCB exists could be misunderstood. When a COOKIE ECHO is
received, a TCB exist and the local and peer's tag match it is stated received, a TCB exist and the local and peer's tag match it is stated
that the endpoint should enter the ESTABLISHED state if it has not that the endpoint should enter the ESTABLISHED state if it has not
already done so and send a COOKIE ACK. It was not clear that in case already done so and send a COOKIE ACK. It was not clear that in case
the endpoint has already left again the ESTABLISHED state then it the endpoint has already left again the ESTABLISHED state then it
should not go back to established. In case D the endpoint can only should not go back to established. In case D the endpoint can only
enter state ESTABLISHED from COOKIE-ECHOED because in state CLOSED it enter state ESTABLISHED from COOKIE-ECHOED because in state CLOSED it
has no TCB and in state COOKIE-WAIT it has a TCB but knows nothing has no TCB and in state COOKIE-WAIT it has a TCB but knows nothing
about the peer's tag which is requested to match in this case. about the peer's tag which is requested to match in this case.
skipping to change at page 59, line 21 skipping to change at page 59, line 21
Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon
Berger, Jon Grim, Dan Harrison, Sabina Torrente, Tomas Orti Martin, Berger, Jon Grim, Dan Harrison, Sabina Torrente, Tomas Orti Martin,
Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Robinson, Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Robinson,
David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Melissa David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Melissa
Campbell, Sujith Radhakrishnan, Andreas Jungmaier, Mitch Miers, Fred Campbell, Sujith Radhakrishnan, Andreas Jungmaier, Mitch Miers, Fred
Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Kacheong Poon, Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Kacheong Poon,
Sverre Slotte, Wang Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep Sverre Slotte, Wang Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep
Mahajan, RCMonee, Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep Mahajan, RCMonee, Ken FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep
Balani, Biren Patel, Qiaobing Xie, Karl Knutson, La Monte Yarroll, Balani, Biren Patel, Qiaobing Xie, Karl Knutson, La Monte Yarroll,
Gareth Keily, Ian Periam, Nathalie Mouellic, Atsushi Fukumoto, David Gareth Keily, Ian Periam, Nathalie Mouellic, Atsushi Fukumoto, David
Lehmann, Rob Brennan, Thomas Curran, and Stan McClellan. Lehmann, Rob Brennan, Thomas Curran, Stan McClellan, Keyur Shah,
Janardhan Iyengar, and Serkan Cil.
A special thanks to Mark Allman, who should actually be a co-author A special thanks to Mark Allman, who should actually be a co-author
for his work on the max-burst, but managed to wiggle out due to a for his work on the max-burst, but managed to wiggle out due to a
technicality. technicality.
References References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [3] Caro, A., Shah, K., Iyengar, J., Amer, P. and R. Stewart, "SCTP
and TCP Variants: Congestion Control Under Multiple Losses",
Technical Report TR2003-04, Computer and Information Sciences
Department, University of Delaware, February 2003, <http://
www.cis.udel.edu/~acaro/publications>.
[4] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window
Validation", RFC 2861, June 2000.
[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
8725 West Higgins Road 8725 West Higgins Road
Suite 300 Suite 300
Chicago, IL 60631 Chicago, IL 60631
skipping to change at page 60, line 37 skipping to change at page 61, line 4
EMail: rrs@cisco.com EMail: rrs@cisco.com
Lyndon Ong Lyndon Ong
Ciena Systems Ciena Systems
10480 Ridgeview Ct 10480 Ridgeview Ct
Cupertino, CA 95014 Cupertino, CA 95014
USA USA
Phone: Phone:
EMail: lyong@ciena.com EMail: lyong@ciena.com
Ivan Arias-Rodriguez Ivan Arias-Rodriguez
Nokia Research Center Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Phone: Phone:
EMail: ivan.arias-rodriguez@nokia.com EMail: ivan.arias-rodriguez@nokia.com
Kacheong Poon Kacheong Poon
Sun Microsysystems, Inc. Consultant
901 San Antonio Road
Palo Alto, CA 94303 Milpitas, CA
USA
Phone: Phone:
EMail: kacheong.poon@sun.com EMail: kcpoon@yahoo.com
Phillip T. Conrad Phillip T. Conrad
Temple University Temple University
CIS Department CIS Department
Room 303, Computer Building (038-24) Room 303, Computer Building (038-24)
1805 N. Broad St. 1805 N. Broad St.
Philadelphia, PA 19122 Philadelphia, PA 19122
US US
Phone: +1 215 204 7910 Phone: +1 215 204 7910
EMail: conrad@acm.org EMail: conrad@acm.org
URI: http://www.cis.temple.edu/~conrad URI: http://www.cis.temple.edu/~conrad
Armando L. Caro Jr. Armando L. Caro Jr.
Department of Computer & Information Sciences University of Delaware University of Delaware
Department of Computer & Information Sciences
103 Smith Hall 103 Smith Hall
Newark, DE 19716 Newark, DE 19716
USA USA
Phone: Phone:
EMail: acaro@cis.udel.edu EMail: acaro@cis.udel.edu
URI: http://www.cis.udel.edu/~acaro
Michael Tuexen Michael Tuexen
Siemens AG
ICN WN CC SE 7
D-81359 Munich
Germany Germany
Phone: Phone:
EMail: Michael.Tuexen@siemens.com EMail: tuexen@fh-muenster.de
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/