draft-ietf-tsvwg-sctpimpguide-04.txt   draft-ietf-tsvwg-sctpimpguide-05.txt 
Internet Engineering Task Force R. Stewart Internet Engineering Task Force R. Stewart
INTERNET DRAFT Cisco Systems INTERNET DRAFT Cisco Systems
L. Ong L. Ong
Ciena Systems Ciena Systems
I. Arias-Rodriguez I. Arias-Rodriguez
Nokia Nokia
K. Poon K. Poon
Sun Microsystems Sun Microsystems
Armando L Caro Jr.
University Of Delaware
expires in six months January 29 2002 expires in six months May 12 2002
SCTP Implementors Guide Stream Control Transmission Protocol (SCTP) Implementers Guide
<draft-ietf-tsvwg-sctpimpguide-04.txt> <draft-ietf-tsvwg-sctpimpguide-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. 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 other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 4 skipping to change at page 2, line 9
January 2002 for the Stream Control Transmission Protocol (SCTP) January 2002 for the Stream Control Transmission Protocol (SCTP)
[RFC2960]. These defects may be of an editorial or technical nature. [RFC2960]. These defects may be of an editorial or technical nature.
This document may be thought of as a companion document to be used in This document may be thought of as a companion document to be used in
the implementation of SCTP to clarify errors in the original SCTP the implementation of SCTP to clarify errors in the original SCTP
document. document.
This document updates RFC2960 and text within this document This document updates RFC2960 and text within this document
supersedes the text found in RFC2960. supersedes the text found in RFC2960.
Table of Contents Table of Contents
1. Introduction.........................................
1.1 Conventions........................................ 1. Introduction......................................... 2
2. Corrections to RFC2960............................... 1.1 Conventions........................................ 3
2.1 Incorrect error type during chunk processing....... 2. Corrections to RFC2960............................... 3
2.2 Parameter processing issue......................... 2.1 Incorrect error type during chunk processing....... 3
2.3 Padding issues..................................... 2.2 Parameter processing issue......................... 3
2.4 Parameter types across all chunk types............. 2.3 Padding issues..................................... 4
2.5 Stream parameter clarification..................... 2.4 Parameter types across all chunk types............. 5
2.6 Restarting association security issue.............. 2.5 Stream parameter clarification..................... 7
2.7 Implicit ability to exceed cwnd by PMTU-1 bytes.... 2.6 Restarting association security issue.............. 8
2.8 Issues with Fast Retransmit........................ 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes....12
2.9 Missing statement about partial_bytes_acked update. 2.8 Issues with Fast Retransmit........................13
2.10 Issues with Heartbeating and failure detection.... 2.9 Missing statement about partial_bytes_acked update.16
2.11 Security interactions with firewalls.............. 2.10 Issues with Heartbeating and failure detection....17
2.12 Shutdown ambiguity................................ 2.11 Security interactions with firewalls..............20
2.13 Inconsistency in ABORT processing................. 2.12 Shutdown ambiguity................................21
2.14 Cwnd gated by its full use in Slow start.......... 2.13 Inconsistency in ABORT processing.................23
2.15 Window probes in SCTP............................. 2.14 Cwnd gated by its full use........................24
2.16 Fragmentation and Path MTU issues................. 2.15 Window probes in SCTP.............................26
2.17 Initial value of the cumulative TSN ACK........... 2.16 Fragmentation and Path MTU issues.................28
2.17 Initial value of the cumulative TSN ACK...........29
2.18 Handling of address parameters within the INIT or 2.18 Handling of address parameters within the INIT or
INIT-ACK.......................................... INIT-ACK..........................................30
2.19 Handling of stream shortages...................... 2.19 Handling of stream shortages......................31
2.20 Indefinite postponement........................... 2.20 Indefinite postponement...........................32
3. Acknowledgments...................................... 3. Acknowledgments......................................33
4. Authors' Addresses................................... 4. Authors' Addresses...................................34
5. References........................................... 5. References...........................................35
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
January 2002 for the Stream Control Transmission Protocol (SCTP) January 2002 for the Stream Control Transmission Protocol (SCTP)
[RFC2960]. These defects may be of an editorial or technical nature. [RFC2960]. These defects may be of an editorial or technical nature.
This document may be thought of as a companion document to be used in This document may be thought of as a companion document to be used in
the implementation of SCTP to clarify errors in the original SCTP the implementation of SCTP to clarify errors in the original SCTP
document. document.
skipping to change at page 13, line 18 skipping to change at page 13, line 24
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. A problem was found in the current specification of fast retransmit.
In particular in a high bandwidth * delay network. The current In particular in a high bandwidth * delay network. The current
wording did not require GAP ACK blocks to be sent, even though they wording did not require GAP ACK blocks to be sent, even though they
are essential to the workings of SCTP's congestion control. Also the are essential to the workings of SCTP's congestion control. Also the
specification left unclear how to handle the fast retransmit cycle, specification left unclear how to handle the fast retransmit cycle,
having the implementation to wait on the cwnd to retransmit a TSN having the implementation to wait on the cwnd to retransmit a TSN
that was marked for fast retransmit. Also no limit was placed on how that was marked for fast retransmit. Also no limit was placed on how
many times a TSN could be fast retransmitted. When recovering from a many times a TSN could be fast retransmitted.
fast retransmit no burst limit was applied as well to prevent an rwnd
clamp down from causing an excessive burst of traffic.
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 16, line 5 skipping to change at page 16, line 7
larger than or equal to 4, mark that chunk for retransmission and larger than or equal to 4, mark that chunk for retransmission and
start the fast retransmit procedure (steps 2-5 above). start the fast retransmit procedure (steps 2-5 above).
M5) If a T3-rtx timer expires, the 'TSN.Missing.Report' of all M5) If a T3-rtx timer expires, the 'TSN.Missing.Report' of all
affected TSNs is set to 0. affected TSNs is set 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.
Upon acknowledgment of a DATA chunk that has been fast retransmitted,
the protocol parameter 'Max.Burst' MUST be applied to limit how many
SCTP packets may be sent upon the completion of SACK processing.
---------
Old text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
---------
New text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4 packets
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.Interval - 30 seconds
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:
- It requires with a MUST the sending of GAP Ack blocks instead of - It requires with a MUST the sending of GAP Ack blocks instead of
the current [RFC2960] SHOULD. the current [RFC2960] SHOULD.
- It allows a TSN being Fast Retransmitted (FR) to be sent only once - It allows a TSN being Fast Retransmitted (FR) to be sent only once
via FR. via FR.
- It ends the delay in awaiting for the flight size to drop when a - 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.
- It applies a Max.Burst parameter to prevent a FR from flooding the
network with packets after rwnd has been clamped to '0' for a
period of time.
- It changes the way chunks are marked during fast retransmit, so - 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 (using M1-M4 above).
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
skipping to change at page 25, line 5 skipping to change at page 24, line 13
Verification Tag field of the packet matches its own tag OR it Verification Tag field of the packet matches its own tag OR it
is set to its peer's tag and the T bit is set in the Chunk is set to its peer's tag and the T bit is set in the Chunk
Flags. Otherwise, the receiver MUST silently discard the packet Flags. Otherwise, the receiver MUST silently discard the packet
and take no further action. and take no further action.
2.13.3 Solution description 2.13.3 Solution description
The above text change clarifies that the T bit must be set before an The above text change clarifies that the T bit must be set before an
implementation looks for the peers tag. implementation looks for the peers tag.
2.14 Cwnd gated by its full use in Slow start 2.14 Cwnd gated by its full use
2.14.1 Description of the problem 2.14.1 Description of the problem
The current wording in section 7.2.1 requires that the cwnd only A problem was found with the current specification of the growth and
be increased if all of the cwnd is being used. The current wording decay of cwnd. The cwnd should only be increased if it is being fully
however is weak and is not clearly defined. utilized, and after periods of under utilization, the cwnd should be
decreased. In some sections, the current wording is weak and is not
clearly defined. Also, the current specification unnecessarily
introduces the need for special case code to ensure cwnd degradation.
2.14.2 Text changes to the document 2.14.2 Text changes to the document
--------- ---------
Old text: (Section 6.1)
---------
D) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B above allow.
---------
New text: (Section 6.1)
---------
D) When the time comes for the sender to transmit new DATA chunks, the
protocol parameter Max.Burst MUST first be applied to limit how many
new DATA chunks may be sent. The limit is applied by adjusting cwnd
as follows:
if((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize + Max.Burst*MTU
E) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B above allow.
---------
Old text: (Section 7.2.1) Old 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 the slow start algorithm to increase cwnd (assuming the use the slow start algorithm to increase cwnd (assuming the
current congestion window is being fully utilized). If an current congestion window is being fully utilized). If an
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
skipping to change at page 25, line 43 skipping to change at page 25, line 23
use the slow start algorithm to increase cwnd only if the use the slow start algorithm to increase cwnd only if the
current congestion window is being fully utilized and an current congestion window is being fully utilized and an
incoming SACK advances the Cumulative TSN Ack Point. Only when incoming SACK advances the Cumulative TSN Ack Point. Only when
these two conditions are met can the cwnd be increased otherwise these two conditions are met can the cwnd be increased otherwise
the cwnd MUST not be increased. If these conditions are met then the cwnd MUST not be increased. If these conditions are met then
cwnd MUST be increased by at most the lesser of 1) the total cwnd MUST be increased by at most the lesser of 1) the total
size of the previously outstanding DATA chunk(s) acknowledged, 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)
---------
o When the endpoint does not transmit data on a given transport
address, the cwnd of the transport address should be adjusted to
max(cwnd/2, 2*MTU) per RTO.
---------
New text: (Section 7.2.1)
---------
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
2*MTU.
---------
Old text: (Section 7.2.2)
---------
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
should be adjusted to max(cwnd / 2, 2*MTU) per RTO.
---------
New text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit DATA on
a given transport address within an RTO, the cwnd of the transport
address should be adjusted to 2*MTU.
---------
Old text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
---------
New text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.Interval - 30 seconds
2.14.3 Solution description 2.14.3 Solution description
The above change to the paragraph strengths the rules and makes The above changes strengthens the rules and makes it much more apparent
it much more apparent as to the need to block cwnd growth when as to the need to block cwnd growth when the full cwnd is not being
the full cwnd is not being utilized. utilized. The changes also applies cwnd degradation without introducing
the need for complex special case code.
2.15 Window probes in SCTP 2.15 Window probes in SCTP
2.15.1 Description of the problem 2.15.1 Description of the problem
When a receiver clamps its rwnd to 0 to flow control the peer, When a receiver clamps its rwnd to 0 to flow control the peer,
the specification implies that one must continue to accept the specification implies that one must continue to accept
data from the remote peer. This is incorrect and needs data from the remote peer. This is incorrect and needs
clarification. clarification.
skipping to change at page 32, line 49 skipping to change at page 33, line 47
2.20.3 Solution description 2.20.3 Solution description
The above wording clarifies how TSNs SHOULD be assigned by The above wording clarifies how TSNs SHOULD be assigned by
the sender. the sender.
3. Acknowledgments 3. Acknowledgments
The authors would like to thank the following people that have The authors would like to thank the following people that have
provided comments and input for this document: provided comments and input for this document:
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 technicality.
For their comments on the list, Atsushi Fukumoto, David Lehmann. For their comments on the list, Atsushi Fukumoto, David Lehmann.
For their participation in the RTP Bakeoff number 2 and all of their For their participation in the RTP Bakeoff number 2 and all of their
input, Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj input, Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj
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 Campbell, David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Melissa Campbell,
Sujith Radhakrishnan, Michael Tuexen, Andreas Jungmaier, Mitch Miers, Sujith Radhakrishnan, Michael Tuexen, Andreas Jungmaier, Mitch Miers,
Fred Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Kacheong Poon, Fred Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Kacheong Poon,
skipping to change at page 33, line 46 skipping to change at page 34, line 48
EMail: ivan.arias-rodriguez@nokia.com EMail: ivan.arias-rodriguez@nokia.com
Kacheong Poon Kacheong Poon
Sun Microsystems, Inc. Sun Microsystems, Inc.
901 San Antonio Road 901 San Antonio Road
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Email: kacheong.poon@sun.com Email: kacheong.poon@sun.com
Armando L. Caro Jr.
Department of Computer & Information Sciences
University of Delaware
103 Smith Hall
Newark, DE 19716, USA
Email: acaro@cis.udel.edu
5. References 5. References
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security [RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
Considerations for IP Fragment Filtering", RFC 1858, Considerations for IP Fragment Filtering", RFC 1858,
October 1995. October 1995.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
 End of changes. 

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