4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
Note: Before the above adjustments, if the received SACK also
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
must be applied first.
A straightforward implementation of the above keeps a counter for
each TSN hole reported by a SACK. The counter increments for each
consecutive SACK reporting the TSN hole. After reaching 4 and
starting the fast retransmit procedure, the counter resets 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.
---------
New text: (Section 7.2.4)
---------
Whenever an endpoint receives a SACK that indicates that some TSNs
are missing, it SHOULD wait for 3 further miss indications (via
subsequent SACKs) on the same TSN(s) before taking action with
regard to Fast Retransmit.
Miss indications SHOULD follow the HTNA (Highest TSN Newly
Acknowledged) 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.
When the fourth consecutive miss indication is received for a TSN(s),
the data sender shall do the following:
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
marked for retransmission will fit into a single packet, subject
to constraint of the path MTU of the destination transport address
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
being performed, the sender SHOULD ignore the value of cwnd and
SHOULD NOT delay retransmission for this single packet.
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
5) Mark the DATA chunk(s) as being fast retransmitted and thus
ineligible for a subsequent fast retransmit. Those TSNs marked
for retransmission due to the Fast Retransmit algorithm that
did not fit in the sent datagram carrying K other TSNs are also
marked as ineligible for a subsequent fast retransmit. However,
as they are marked for retransmission they will be retransmitted
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 due to a subsequent Fast
Recovery event (i.e., one SHOULD NOT reduce the cwnd further due
to a subsequent fast retransmit).
Note: Before the above adjustments, if the received SACK also
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
must be applied first.
2.8.3. Solution Description
The effect of the above wording changes are as follows:
o It requires with a MUST the sending of GAP Ack blocks instead of
the current RFC 2960 [5] SHOULD.
o It allows a TSN being Fast Retransmitted (FR) to be sent only once
via FR.
o It ends the delay in waiting for the flight size to drop when a
TSN is identified as being ready to FR.
o It changes the way chunks are marked during fast retransmit, so
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
as TCP+SACK in the handling of Fast Retransmit.
2.9. Missing Statement about partial_bytes_acked Update
2.9.1. Description of the Problem
SCTP uses four control variables to regulate its transmission rate:
rwnd, cwnd, ssthresh, and partial_bytes_acked. Upon detection of
packet losses from SACK, or when the T3-rtx timer expires on an
address, cwnd and ssthresh should be updated as stated in Section
7.2.3. However, that section should also clarify that
partial_bytes_acked must be updated as well; it has to be reset to 0.
2.9.2. Text Changes to the Document
---------
Old text: (Section 7.2.3)
---------
7.2.3 Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), An
endpoint should do the following:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
When the T3-rtx timer expires on an address, SCTP should perform slow
start by:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
---------
New text: (Section 7.2.3)
---------
7.2.3. Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), an
endpoint should do the following if not in Fast Recovery:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
partial_bytes_acked = 0
Basically, a packet loss causes cwnd to be cut in half.
When the T3-rtx timer expires on an address, SCTP should perform slow
start by
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
partial_bytes_acked = 0
2.9.3. Solution Description
The missing text added solves the doubts about what to do with
partial_bytes_acked in the situations stated in Section 7.2.3, making
clear that, along with ssthresh and cwnd, partial_bytes_acked should
also be updated by being reset to 0.
2.10. Issues with Heartbeating and Failure Detection
2.10.1. Description of the Problem
Five basic problems have been discovered with the current heartbeat
procedures:
o The current specification does not specify that you should count a
failed heartbeat as an error against the overall association.
o The current specification is not specific as to when you start
sending heartbeats and when you should stop.
o The current specification is not specific as to when you should
respond to heartbeats.
o When responding to a Heartbeat, it is unclear what to do if more
than a single TLV is present.
o The jitter applied to a heartbeat was meant to be a small variance
of the RTO and is currently a wide variance, due to the default
delay time and incorrect wording within the RFC.
2.10.2. Text Changes to the Document
---------
Old text: (Section 8.1)
---------
8.1 Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (including retransmissions to all the
destination transport addresses of the peer if it is multi-homed).
If the value of this counter exceeds the limit indicated in the
protocol parameter ’Association.Max.Retrans’, the endpoint shall
consider the peer endpoint unreachable and shall stop transmitting
any more data to it (and thus the association enters the CLOSED
state). In addition, the endpoint shall report the failure to the
upper layer, and optionally report back all outstanding user data
remaining in its outbound queue. The association is automatically
closed when the peer endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint.
---------
New text: (Section 8.1)
---------
8.1. Endpoint Failure Detection
An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (this includes retransmissions to all the
destination transport addresses of the peer if it is multi-homed),
including unacknowledged HEARTBEAT Chunks. If the value of this
counter exceeds the limit indicated in the protocol parameter
’Association.Max.Retrans’, the endpoint shall consider the peer
endpoint unreachable and shall stop transmitting any more data to it
(and thus the association enters the CLOSED state). In addition, the
endpoint MAY report the failure to the upper layer and optionally
report back all outstanding user data remaining in its outbound
queue. The association is automatically closed when the peer
endpoint becomes unreachable.
The counter shall be reset each time a DATA chunk sent to that peer
endpoint is acknowledged (by the reception of a SACK), or a
HEARTBEAT-ACK is received from the peer endpoint.
---------
Old text: (Section 8.3)
---------
8.3 Path Heartbeat
By default, an SCTP endpoint shall 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).
---------
New text: (Section 8.3)
---------
8.3 Path Heartbeat
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).
---------
Old text: (Section 8.3)
---------
The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the Heartbeat Information field copied
from the received HEARTBEAT chunk.
---------
New text: (Section 8.3)
---------
The receiver of the HEARTBEAT should immediately respond with a
HEARTBEAT ACK that contains the Heartbeat Information TLV, together
with any other received TLVs, copied unchanged from the received
HEARTBEAT chunk.
---------
Old text: (Section 8.3)
---------
On an idle destination address that is allowed to heartbeat, a
HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that
destination address plus the protocol parameter ’HB.interval’ , with
jittering of +/- 50%, and exponential back-off of the RTO if the
previous HEARTBEAT is unanswered.
---------
New text: (Section 8.3)
---------
On an idle destination address that is allowed to heartbeat, it is
recommended that a HEARTBEAT chunk is sent once per RTO of that
destination address plus the protocol parameter ’HB.interval’, with
jittering of +/- 50% of the RTO value, and exponential back-off of
the RTO if the previous HEARTBEAT is unanswered.
2.10.3. Solution Description
The above text provides guidance as to how to respond to the five
issues mentioned in Section 2.10.1. In particular, the wording
changes provide guidance as to when to start and stop heartbeating,
how to respond to a heartbeat with extra parameters, and it clarifies
the error counting procedures for the association.
2.11. Security interactions with firewalls
2.11.1. Description of the Problem
When dealing with firewalls, it is advantageous for the firewall to
be able to properly determine the initial startup sequence of a
reliable transport protocol. With this in mind, the following text
is to be added to SCTP’s security section.
2.11.2. Text Changes to the Document
---------
New text: (no old text, new section added)
---------
11.4 SCTP Interactions with Firewalls
It is helpful for some firewalls if they can inspect
just the first fragment of a fragmented SCTP packet and unambiguously
determine whether it corresponds to an INIT chunk (for further
information, please refer to RFC1858). Accordingly, we
stress the requirements, stated in 3.1, that (1) an INIT chunk MUST
NOT be bundled with any other chunk in a packet, and (2) a packet
containing an INIT chunk MUST have a zero Verification Tag.
Furthermore, we require that the receiver of an INIT chunk MUST
enforce these rules by silently discarding an arriving packet with an
INIT chunk that is bundled with other chunks.
---------
Old text: (Section 18)
---------
18. Bibliography
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM’99, 1999.
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
---------
New text: (Section 18)
---------
18. Bibliography
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM’99, 1999.
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
2.11.3. Solution Description
The above text, which adds a new subsection to the Security
Considerations section of RFC 2960 [5] makes clear that, to make
easier the interaction with firewalls, an INIT chunk must not be
bundled in any case with any other chunk that will silently discard
the packets that do not follow this rule (this rule is enforced by
the packet receiver).
2.12. Shutdown Ambiguity
2.12.1. Description of the Problem
Currently, there is an ambiguity between the statements in Sections
6.2 and 9.2. Section 6.2 allows the sending of a SHUTDOWN chunk in
place of a SACK when the sender is in the process of shutting down,
while section 9.2 requires that both a SHUTDOWN chunk and a SACK
chunk be sent.
Along with this ambiguity there is a problem wherein an errant
SHUTDOWN receiver may fail to stop accepting user data.
2.12.2. Text Changes to the Document
---------
Old text: (Section 9.2)
---------
If there are still outstanding DATA chunks left, the SHUTDOWN
receiver shall continue to follow normal data transmission procedures
defined in Section 6 until all outstanding DATA chunks are
acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
from its SCTP user.
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
respond to each received packet containing one or more DATA chunk(s)
with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If
it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
entering the SHUTDOWN-ACK-SENT state. If the timer expires, the
endpoint must re-send the SHUTDOWN ACK.
---------
New text: (Section 9.2)
---------
If there are still outstanding DATA chunks left, the SHUTDOWN
receiver MUST continue to follow normal data transmission procedures
defined in Section 6, until all outstanding DATA chunks are
acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
from its SCTP user.
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
respond to each received packet containing one or more DATA chunks
with a SHUTDOWN chunk and restart the T2-shutdown timer. If a
SHUTDOWN chunk by itself cannot acknowledge all of the received DATA
chunks (i.e., there are TSNs that can be acknowledged that are larger
than the cumulative TSN, and thus gaps exist in the TSN sequence), or
if duplicate TSNs have been received, then a SACK chunk MUST also be
sent.
The sender of the SHUTDOWN MAY also start an overall guard timer
’T5-shutdown-guard’ to bound the overall time for shutdown sequence.
At the expiration of this timer, the sender SHOULD abort the
association by sending an ABORT chunk. If the ’T5-shutdown-guard’
timer is used, it SHOULD be set to the recommended value of 5 times
’RTO.Max’.
If the receiver of the SHUTDOWN has no more outstanding DATA chunks,
the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a
T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state.
If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
2.12.3. Solution Description
The above text clarifies the use of a SACK in conjunction with a
SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown
sequence to protect against errant receivers of SHUTDOWN chunks.
2.13. Inconsistency in ABORT Processing
2.13.1. Description of the Problem
It was noted that the wording in Section 8.5.1 did not give proper
directions in the use of the ’T bit’ with the Verification Tags.
2.13.2. Text changes to the document
---------
Old text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
- The endpoint shall always fill in the Verification Tag field
of the outbound packet with the destination endpoint’s tag
value if it is known.
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4.
- The receiver MUST accept the packet if the Verification Tag
matches either its own tag, OR the tag of its peer. Otherwise,
the receiver MUST silently discard the packet and take no
further action.
---------
New text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
- The endpoint MUST always fill in the Verification Tag field of
the outbound packet with the destination endpoint’s tag value,
if it is known.
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4.
- The receiver of a ABORT MUST accept the packet if the
Verification Tag field of the packet matches its own tag OR if
it 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 and take no further action.
2.13.3. Solution Description
The above text change clarifies that the T bit must be set before an
implementation looks for the peer’s tag.
2.14. Cwnd Gated by Its Full Use
2.14.1. Description of the Problem
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
fully utilized, and after periods of underutilization, 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. 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
---------
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 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.
E) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B allow.
---------
Old text: (Section 7.2.1)
---------
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
use the slow start algorithm to increase cwnd (assuming the
current congestion window is being fully utilized). If an
incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be
increased by at most the lesser of 1) the total size of the
previously outstanding DATA chunk(s) acknowledged, and 2) the
destination’s path MTU. This protects against the ACK-Splitting
attack outlined in [SAVAGE99].
---------
New text: (Section 7.2.1)
---------
o When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST
use the slow start algorithm to increase cwnd only if the current
congestion window is being fully utilized, an incoming SACK
advances the Cumulative TSN Ack Point, and the data sender is not
in Fast Recovery. Only when these three conditions are met can
the cwnd be increased; otherwise, the cwnd MUST not be increased.
If these conditions are met, then cwnd MUST be increased by, at