draft-ietf-tsvwg-sctp-failover-03.txt   draft-ietf-tsvwg-sctp-failover-04.txt 
Network Working Group Y. Nishida Network Working Group Y. Nishida
Internet-Draft GE Global Research Internet-Draft GE Global Research
Intended status: Experimental P. Natarajan Intended status: Experimental P. Natarajan
Expires: September 3, 2014 Cisco Systems Expires: December 30, 2014 Cisco Systems
A. Caro A. Caro
BBN Technologies BBN Technologies
P. Amer P. Amer
University of Delaware University of Delaware
K. Nielsen K. Nielsen
Ericsson Ericsson
March 2, 2014 June 28, 2014
Quick Failover Algorithm in SCTP Quick Failover Algorithm in SCTP
draft-ietf-tsvwg-sctp-failover-03.txt draft-ietf-tsvwg-sctp-failover-04.txt
Abstract Abstract
One of the major advantages of SCTP is supporting multi-homed One of the major advantages of SCTP is that it supports multi-homed
communication. If a multi-homed end-point has a redundant network communication. A multi-homed SCTP end-point has the ability to
connections, the SCTP associations have a good chance to survive withstand network failures by migrating the traffic from an inactive
network failures by migrating traffic from inactive networks to network to an active one. However, if the [RFC4960] specified
active ones. However, if the SCTP standard is followed, there can be failover operation is followed there can be a significant delay in
a significant delay during the migration. During this period, SCTP the migration to the active destination addresses, thus severely
might not be able to transmit much data to the peer. This issue reducing the effectiveness of SCTP multi-homed operation.
drastically impairs the usability of SCTP in some situations. This
memo describes the issue of the SCTP failover mechanism and specifies
an alternative failover procedure for SCTP that improves its
performance during and after failover. The procedures require only
minimal modifications to the current specification.
Status of this Memo The memo complements RFC4960 by the introduction of the Potentially
Failed state and associated new Quick Failover operation to apply
during network failure and specifies for SCTP senders to support this
more performance optimal failover procedure as an add-on to the
[RFC4960] failover operation. The memo in addition updates [RFC4960]
by clarifying a number of issues related to the path management
operation during periods of partial or complete network failures.
Finally the memo complements [RFC4960] by introduction of alternative
switchover operation modes for the data transfer path management
after a failover. These operation modes offer for more performance
optimal operation in some network environments. From the perspective
of this memo the implementation of the additional switchover
operation modes is considered optional.
The procedures defined require only minimal modifications to the
current specification. The procedures are sender-side only and do
not impact the SCTP receiver.
Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2014. This Internet-Draft will expire on December 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Issues with the SCTP Path Management . . . . . . . . . . . . . 5 3. Issues with the SCTP Path Management . . . . . . . . . . . . 4
4. Existing Solutions for Smooth Failover . . . . . . . . . . . . 6 4. SCTP with Potentially-Failed Destination State (SCTP-PF) . . 5
4.1. Reduce Path.Max.Retrans (PMR) . . . . . . . . . . . . . . 6 4.1. SCTP-PF Description . . . . . . . . . . . . . . . . . . . 5
4.2. Adjust RTO related parameters . . . . . . . . . . . . . . 6 4.2. Permanent Failover . . . . . . . . . . . . . . . . . . . 9
5. SCTP with Potentially-Failed Destination State (SCTP-PF) . . . 8 5. Socket API Considerations . . . . . . . . . . . . . . . . . . 10
5.1. SCTP-PF Description . . . . . . . . . . . . . . . . . . . 8 5.1. Support for the Potentially Failed Path State . . . . . . 11
5.2. Effect of Path Bouncing . . . . . . . . . . . . . . . . . 10 5.2. Peer Address Thresholds (SCTP_PEER_ADDR_THLDS) Socket
5.3. Permanent Failover . . . . . . . . . . . . . . . . . . . . 10 Option . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Socket API Considerations . . . . . . . . . . . . . . . . . . 12 5.3. Exposing the Potentially Failed Path State
6.1. Support for the Potentially Failed Path State . . . . . . 12 (SCTP_EXPOSE_POTENTIALLY_FAILED_STATE) Socket Option . . 13
6.2. Peer Address Thresholds (SCTP_PEER_ADDR_THLDS) Socket 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
Option . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.3. Exposing the Potentially Failed Path State 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
(SCTP_EXPOSE_POTENTIALLY_FAILED_STATE) Socket Option . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Discussions of Alternative Approaches . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 A.1. Reduce Path.Max.Retrans (PMR) . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 A.2. Adjust RTO related parameters . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix B. Discussions for Path Bouncing Effect . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Stream Control Transmission Protocol (SCTP) as specified in The Stream Control Transmission Protocol (SCTP) as specified in
[RFC4960] supports multihoming at the transport layer -- an SCTP [RFC4960] supports multihoming at the transport layer -- an SCTP
association can bind to multiple IP addresses at each endpoint. association can bind to multiple IP addresses at each endpoint.
SCTP's multihoming features include failure detection and failover SCTP's multihoming features include failure detection and failover
procedures to provide network interface redundancy and improved end- procedures to provide network interface redundancy and improved end-
to-end fault tolerance. to-end fault tolerance.
skipping to change at page 3, line 28 skipping to change at page 3, line 36
failure detection. Until detecting the failover, the sender failure detection. Until detecting the failover, the sender
continues to transmit data on the failed path, which degrades the continues to transmit data on the failed path, which degrades the
SCTP performance. Concurrent Multipath Transfer (CMT) [IYENGAR06] is SCTP performance. Concurrent Multipath Transfer (CMT) [IYENGAR06] is
an extension to SCTP and allows the sender to transmit data on an extension to SCTP and allows the sender to transmit data on
multiple paths simultaneously. Research [NATARAJAN09] shows that the multiple paths simultaneously. Research [NATARAJAN09] shows that the
current failure detection procedure worsens CMT performance during current failure detection procedure worsens CMT performance during
failover and can be significantly improved by employing a better failover and can be significantly improved by employing a better
failover algorithm. failover algorithm.
This document specifies an alternative failure detection procedure This document specifies an alternative failure detection procedure
for SCTP (and CMT) that improves the SCTP (and CMT) performance for SCTP that improves the SCTP performance during a failover.
during a failover.
Also the operation after a failover impacts the performance of the Also the operation after a failover impacts the performance of the
protocol. With [RFC4960] procedures, SCTP will, after a failover protocol. With [RFC4960] procedures, SCTP will, after a failover
from the primary path, switch back to use the primary path for data from the primary path, switch back to use the primary path for data
transfer as soon as this path becomes available. From a performance transfer as soon as this path becomes available. From a performance
perspective, as confirmed in research [CARO02], such a switchback of perspective, as confirmed in research [CARO02], such a switchback of
the data transmission path is not optimal in general. As an the data transmission path is not optimal in general. As an optional
alternative option to the switchback operation of [RFC4960], this alternative to the switchback operation of [RFC4960], this document
document specifies the support the Permanent Failover switchover specifies for SCTP to support the Permanent Failover switchover
procedures proposed by [CARO02]. procedures proposed by [CARO02].
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Issues with the SCTP Path Management 3. Issues with the SCTP Path Management
This section describes issues in the current SCTP to be fixed by the
approach described in this document.
SCTP can utilize multiple IP addresses for a single SCTP association. SCTP can utilize multiple IP addresses for a single SCTP association.
Each SCTP endpoint exchanges the list of its usable addresses during Each SCTP endpoint exchanges the list of its usable addresses during
initial negotiation with its peer. Then the endpoints select one initial negotiation with its peer. Then the endpoints select one
address from the peer's list and define this as the primary address from the peer's list and define this as the primary
destination. During normal transmission, SCTP sends all user data to destination. During normal transmission, SCTP sends all user data to
the primary destination. Also, it sends heartbeat packets to all the primary destination. Also, it sends heartbeat packets to all
idle destinations at a certain interval to check the reachability of idle destinations at a certain interval to check the reachability of
the path. Idle destinations normally include all non-primary the path. Idle destinations normally include all non-primary
destinations. destinations.
skipping to change at page 5, line 46 skipping to change at page 5, line 6
One issue with this failover process is that it usually takes One issue with this failover process is that it usually takes
significant amount of time before SCTP switches to the new significant amount of time before SCTP switches to the new
destination. Let's say the primary path on a multi-homed host destination. Let's say the primary path on a multi-homed host
becomes unavailable and the RTO value for the primary path at that becomes unavailable and the RTO value for the primary path at that
time is around 1 second, it usually takes over 60 seconds before SCTP time is around 1 second, it usually takes over 60 seconds before SCTP
starts to use the secondary path. This is because the recommended starts to use the secondary path. This is because the recommended
value for Path.Max.Retrans in the standard is 5, which requires 6 value for Path.Max.Retrans in the standard is 5, which requires 6
consecutive timeouts before failover takes place. Before SCTP consecutive timeouts before failover takes place. Before SCTP
switches to the secondary address, SCTP keeps trying to send packets switches to the secondary address, SCTP keeps trying to send packets
to the primary and only retransmitted packets are sent to the to the primary and only retransmitted packets are sent to the
secondary can be reached at the receiver. This slow failover process secondary and can thus be reached at the receiver. This slow
can cause significant performance degradation and will not be failover process can cause significant performance degradation and
acceptable in some situations. will not be acceptable in some situations.
Another issue is that once the primary path is active again, the Another issue is that once the primary path is active again, the
traffic is switched back. This is not optimal in general. traffic is switched back. This is not optimal in some situations.
This is further discussed in Section 4.2.
4. Existing Solutions for Smooth Failover
The following approaches are conceivable for the solutions of this
issue.
4.1. Reduce Path.Max.Retrans (PMR)
Smaller values for Path.Max.Retrans shorten the failover duration.
In fact, this is recommended in some research results [JUNGMAIER02]
[GRINNEMO04] [FALLON08]. For example, if when Path.Max.Retrans=0,
SCTP switches to another destination on a single timeout. However,
smaller value for Path.Max.Retrans also results in spurious failover.
In addition, smaller Path.Max.Retrans values also affect
'Association.Max.Retrans' values. When the SCTP association's error
count (sum of error counts on all ACTIVE paths) exceeds
Association.Max.Retrans threshold, the SCTP sender considers the peer
endpoint unreachable and terminates the association. Therefore,
Section 8.2 in [RFC4960] recommends that Association.Max.Retrans
value should not be larger than the summation of the Path.Max.Retrans
of each of the destination addresses, else the SCTP sender considers
its peer reachable even when all destinations are INACTIVE. To avoid
such inconsistent behavior an SCTP implementation SHOULD reduce
Association.Max.Retrans accordingly whenever it reduces
Path.Max.Retrans. However, smaller Association.Max.Retrans value
increases chances of association termination during minor congestion
events.
Another issue is that the interval of heartbeat packet: 'HB.interval'
could be in the order of seconds (recommended value is 30 seconds).
When the primary path becomes inactive, the next HB can be
transmitted only seconds later. Meanwhile, the primary path may have
recovered. In such situations, post failover, an endpoint is forced
to wait on the order of seconds before the endpoint can resume
transmission on the primary path.
The advantage of tuning Path.Max.Retrans is that it requires no
modification to the current standard. However, as we discuss above
tuning Path.Max.Retrans ignores several recommendations in [RFC4960].
In addition, some research results indicate path bouncing caused by
spurious failover does not cause serious problems. We discuss the
effect of path bouncing in Section 5.2.
4.2. Adjust RTO related parameters
As several research results indicate, we can also shorten the
duration of failover process by adjusting RTO related parameters
[JUNGMAIER02] [FALLON08]. During failover process, RTO keeps being
doubled. However, if we can choose smaller value for RTO.max, we can
stop the exponential growth of RTO at some point. Also, choosing
smaller values for RTO.initial or RTO.min can contribute to keep RTO
value small.
Similar to reducing Path.Max.Retrans, the advantage of this approach 4. SCTP with Potentially-Failed Destination State (SCTP-PF)
is that it requires no modification to the current specification,
although it needs to ignore several recommendations described in the
Section 15 of [RFC4960]. However, this approach requires to have
enough knowledge about the network characteristics between end
points. Otherwise, it can introduce adverse side-effects such as
spurious timeouts.
5. SCTP with Potentially-Failed Destination State (SCTP-PF) In order to address the issues described in Section 3, We propose to
update SCTP path management scheme as follows.
5.1. SCTP-PF Description 4.1. SCTP-PF Description
SCTP-PF stems from the following two observations about SCTP's SCTP-PF stems from the following two observations about SCTP's
failure detection procedure: failure detection procedure:
o In order to minimize performance impact during failover, the o In order to minimize performance impact during failover, the
sender should avoid transmitting data to the failed destination as sender should avoid transmitting data to the failed destination as
early as possible. In the current SCTP path management scheme, early as possible. In the current SCTP path management scheme,
the sender stops transmitting data to a destination only after the the sender stops transmitting data to a destination only after the
destination is marked Failed. Thus, a smaller PMR value is ideal destination is marked Failed (inactive). Thus, a smaller PMR
so that the sender transitions a destination to the Failed state value is ideal so that the sender transitions a destination to the
quicker. Failed (inactive) state quicker.
o Smaller PMR values increase the chances of spurious failure o Smaller PMR values increase the chances of spurious failure
detection where the sender incorrectly marks a destination as detection where the sender incorrectly marks a destination as
Failed during periods of temporary congestion. Larger PMR values Failed (inactive) during periods of temporary congestion. As
are preferable to avoid spurious failure detection. [RFC4960] recommends for a coupling of the PMR value and the AMR
value such spurious failure detection risks to carry over to
spurious association failure detection and closure. Larger PMR
values are preferable to avoid spurious failure detection.
From the above observations it is clear that tweaking the PMR value From the above observations it is clear that tweaking the PMR value
involves the following tradeoff -- a lower value improves performance involves the following tradeoff -- a lower value improves performance
but increases the chances of spurious failure detection, whereas a but increases the chances of spurious failure detection, whereas a
higher value degrades performance and reduces spurious failure higher value degrades performance and reduces spurious failure
detection in a wide range of path conditions. Thus, tweaking the detection in a wide range of path conditions. Thus, tweaking the
association's PMR value is an incomplete solution to address association's PMR value is an incomplete solution to address
performance impact during failure. performance impact during failure.
This proposal introduces a new "Potentially-failed" (PF) destination This proposal introduces a new "Potentially-Failed" (PF) destination
state in SCTP's path management procedure. The PF state was state in SCTP's path management procedure. The PF state was
originally proposed to improve CMT performance [NATARAJAN09]. The PF originally proposed to improve CMT performance [NATARAJAN09]. The PF
state is an intermediate state between Active and Failed states. state is an intermediate state between Active and Failed states.
SCTP's failure detection procedure is modified to include the PF SCTP's failure detection procedure is modified to include the PF
state. The new failure detection algorithm assumes that loss state. The new failure detection algorithm assumes that loss
detected by a timeout implies either severe congestion or failure en- detected by a timeout implies either severe congestion or failure en-
route. After a number of consecutive timeouts on a path, the sender route. After a number of consecutive timeouts on a path, the sender
is unsure, and marks the corresponding destination as PF. A PF is unsure, and marks the corresponding destination as PF. A PF
destination is not used for data transmission except in special cases destination is not used for data transmission except in special cases
(discussed below). The new failure detection algorithm requires only (discussed below). The new failure detection algorithm requires only
sender-side changes. Details are: sender-side changes. The details are:
1. The sender maintains a new tunable parameter called Potentially-
failed.Max.Retrans (PFMR). The recommended value of PFMR = 0
when quick failover is used. When PFMR is larger or equal to
PMR, quick failover is turned off.
2. Each time the T3-rtx timer expires on an active destination, the
error counter of that destination address will be incremented.
When the value in the error counter exceeds PFMR, the endpoint
should mark the destination transport address as PF.
3. The sender SHOULD avoid data transmission to PF destinations.
When all destinations are in either PF or Inactive state, the
sender MAY either move the destination from PF to Active state
(and transmit data to the active destination) or the sender MAY
transmit data to a PF destination. In the former scenario, (i)
the sender MUST NOT notify the ULP about the state transition,
and (ii) MUST NOT clear the destination's error counter. It is
recommended that the sender picks the PF destination with least
error count (fewest consecutive timeouts) for data transmission.
In case of a tie (multiple PF destinations with same error
count), the sender MAY choose the last active destination.
4. Only heartbeats MUST be sent to PF destination(s) once per RTO. 1. The sender maintains a new tunable parameter called Potentially-
This means the sender SHOULD ignore HB.interval for PF Failed.Max.Retrans (PFMR). The recommended value of PFMR = 0
destinations. If an heartbeat is unanswered, the sender when quick failover is used. When PFMR is larger or equal to
increments the error counter and exponentially backs off the RTO PMR, quick failover is turned off.
value. If error counter is less than PMR, the sender SHOULD
transmit another heartbeat immediately after T3-timer expiration.
5. When the sender receives an heartbeat ACK from a PF destination, 2. The error counter of an active destination address is
the sender clears the destination's error counter and transitions incremented as specified in [RFC4960]. This means that the
the PF destination back to Active state. The sender should error counter of the destination address will be incremented
perform slow-start as specified in Section 7.2.1 of [RFC4960] each time the T3-rtx timer expires, or at times where a
when it sends data on this destination. HEARTBEAT sent to an idle, active address is not acknowledged
within an RTO. When the value in the destination address error
counter exceeds PFMR, the endpoint MUST mark the destination
transport address as PF.
6. Additional (PMR - PFMR) consecutive timeouts on a PF destination 3. The sender SHOULD avoid data transmission to PF destinations.
confirm the path failure, upon which the destination transitions When the destinations are all in PF state or some in PF state
to the Inactive state. As described in [RFC4960], the sender (i) and some in inactive state, the sender MUST choose one
SHOULD notify ULP about this state transition, and (ii) transmit destination in PF state and transmit data to this destination.
heartbeats to the Inactive destination at a lower frequency as The sender SHOULD choose the destination in PF state with least
described in Section 8.3 of [RFC4960]. error count (fewest consecutive timeouts) for data transmission
and transmit data to this destination. In case of multiple PF
destinations with same error count, the sender SHOULD let the
choice among the multiple PF destination with equal error count
be based on the [RFC4960], section 6.4.1, principles of choosing
most divergent source-destination pairs when executing
(potentially consecutive) retransmission. This means that the
sender SHOULD attempt to pick the most divergent source -
destination pair from the last source - destination pair on
which data were transmitted or retransmitted. Rules for picking
the most divergent source-destination pair are an implementation
decision and are not specified within this document. A sender
MAY choose to deploy other strategies than the above when
choosing among multiple PF destinations with equal error count.
In all cases the sender MUST NOT change the state of chosen
destination and it MUST NOT clear the destination's error
counter as a result of choosing the destination for data
transmission.
7. When all destinations are in the Inactive state, the sender picks 4. Heartbeats SHOULD be sent to PF destination(s) once per RTO.
one of the Inactive destinations for data transmission. This This means the sender MUST ignore HB.interval for PF
proposal recommends that the sender picks the Inactive destinations. If an heartbeat is unanswered, the sender SHOULD
destination with least error count (fewest consecutive timeouts) increment the error counter and exponentially back off the RTO
for data transmission. In case of a tie (multiple Inactive value. If error counter is less than PMR, the sender SHOULD
destinations with same error count), the sender MAY choose the transmit another heartbeat immediately after T3-timer
last active destination. expiration. When data is transmitted to a PF destination the
transmittal of heartbeats may be omitted as SACK or T3-rtx timer
expiration can provide equivalent information. This
specification recommends that heartbeats be send to PF
destinations independently from whether the Path Heartbeat
function (Section 8.3 of [RFC4960]) is enabled for the
destination address or not.
8. ACKs for retransmissions do not transition a PF destination back 5. When the sender receives an heartbeat ACK from a PF destination,
to Active state, since a sender cannot disambiguate whether the the sender MUST clear the destination's error counter and
ack was for the original transmission or the retransmission(s). transition the PF destination back to Active state. When the
sender resumes data transmission on the destination it MUST do
this following the prescriptions of Section 7.2 of [RFC4960].
9. SCTP shall provide the means to expose the PF state of its 6. Additional (PMR - PFMR) consecutive timeouts on a PF destination
destinations as well as SCTP SHOULD notify the ULP of the state confirm the path failure, upon which the destination transitions
transitions from Active to PF and from PF to Active state. SCTP to the Inactive state. As described in [RFC4960], the sender
can provide the means to suppress exposure of PF state and (i) SHOULD notify ULP about this state transition, and (ii)
association state transitions and in this case the ULP MAY make transmit heartbeats to the Inactive destination at a lower
SCTP suppress exposure of PF state to ULP. In this case the ULP frequency as described in Section 8.3 of [RFC4960] (when this
will rely solely on the [RFC4960] state machine even if quick function is enabled for the destination address).
failover function is activated in SCTP.
5.2. Effect of Path Bouncing 7. When all destinations are in inactive state (association dormant
state) the sender MUST also choose one destination to transmit
data to. The sender SHOULD choose the destination in inactive
state with least error count (fewest consecutive timeouts) for
data transmission and transmit data to this destination. In
case of multiple destinations with same error count in inactive
state, the sender SHOULD attempt to pick the most divergent
source - destination pair from the last source - destination
pair on which data were transmitted or retransmitted following
[RFC4960]. Rules for picking the most divergent source-
destination pair are an implementation decision and are not
specified within this document. In order to support this
prescription a sender SHOULD allow for increment of the
destination error counters up to some reasonable limit above
PMR+1, thus changing the prescriptions of [RFC4960], section
8.3, in this respect. The exact limit to apply is not specified
in this document but it is considered reasonable to require for
such to be an order of magnitude higher than the PMR value. A
sender MAY choose to deploy other strategies than the above.
For example, a sender could choose to prioritize the last active
destination during dormant state. The strategy to prioritize
the last active destination is optimal when some paths are
permanently inactive, but suboptimal when paths' instability is
transient. While the increment of the error counters above
PMR+1 is a prerequisite for the error counter values to serve to
guide the path selection in dormant state, then it is noted that
by virtue of the introduction of the Potentially Failed state,
one may deploy higher values of PMR without compromising the
efficiency of the failover operation, and thus making the
increase of path error counters above PMR+1 less critical as the
dormant state will be less likely to happen. The downside of
increasing the PMR value relative to the AMR value, however, is
that the per destination address failure detection and
notification of such to ULP thereby is weakened. In all cases
the sender MUST NOT change the state of the chosen destination
and it MUST NOT clear the destination's error counter as a
result of choosing the destination for data transmission.
The methods described above can accelerate the failover process. 8. ACKs for chunks which have been transmitted to multiple
Hence, they might introduce the path bouncing effect where the sender destinations (i.e., a chunk which has been retransmitted to a
keeps changing the data transmission path frequently. This sounds different destination than the destination to which the chunk
harmful to the data transfer, however several research results was first transmitted) SHOULD NOT clear the error count of an
indicate that there is no serious problem with SCTP in terms of path inactive destination and SHOULD NOT transition a PF destination
bouncing effect [CARO04] [CARO05]. back to Active state, since a sender cannot disambiguate whether
the ack was for the original transmission or the
retransmission(s). The same ambiguity concerns the related
congestion window growth. In this respect then it is specified
that bytes of a newly acknowledged chunk which has been
transmitted to multiple destinations SHOULD, when the conditions
for such contribution is fulfilled following the prescriptions
of Section 7.2 of [RFC4960], contribute to the congestion window
growth towards the destination to which the chunk was last
transmitted. A SCTP sender MAY apply a different approach for
both the error count handling as well as the congestion control
growth handling does it have unequivocally information as to
which destination (including multiple destinations) the chunk
reached. This document makes no reference to what such
unequivocally information could consist of, neither how such
unequivocally information could be obtained. The implementation
of such an alternative approach is left to implementations.
There are two main reasons for this. First, SCTP is basically 9. ACKs for chunks which has been transmitted to one destination
designed for multipath communication, which means SCTP maintains all address only MUST clear the error counter of the destination
path related parameters (CWND, ssthresh, RTT, error count, etc) per address and MUST transition a PF destination back to Active
each destination address. These parameters cannot be affected by state. This situation can happen when new data is sent to a
path bouncing. In addition, when SCTP migrates the data transfer to destination address in PF state. It can also happen in
another path, it starts with the minimal or the initial CWND. Hence, situations where the destination address is in PF state due to
there is little chance for packet reordering or duplicating. the occurrence of a spurious T3-rtx timer and ACKs start to
arrive for data sent prior to occurrence of the spurious T3-rtx
and data has not yet been retransmitted towards other
destinations. This document does not specify special handling
for detection of or reaction to spurious T3-rtx timeouts, e.g.,
for special operation vis-a-vis the congestion control handling
or data retransmission operation towards a destination address
which undergoes a transition from active to PF to active state
due to a spurious T3-rtx timeout. But it is noted that this is
an area which would benefit from additional attention,
experimentation and specification for Single Homed SCTP as well
as for Multi Homed SCTP protocol operation.
Second, even if all communication paths between the end-nodes share 10. SCTP SHOULD provide the means to expose the PF state of its
the same bottleneck, the quick failover results in a behavior already destinations as well as the means to notify the ULP of the state
allowed by [RFC4960]. transitions from Active to PF and from PF to Active state . When
doing such SCTP MUST provide the means to suppress exposure of
PF state and association state transitions and in this case the
ULP MAY make SCTP suppress exposure of PF state to ULP. If
exposure of PF state is suppressed, the ULP will rely solely on
the [RFC4960] state machine even if Quick Failover function is
activated in SCTP.
5.3. Permanent Failover 4.2. Permanent Failover
Post failover then, by [RFC4960] behavior, an SCTP sender migrates Post failover then, by [RFC4960] behavior, an SCTP sender migrates
the traffic back to the original primary destination once this the traffic back to the original primary destination once this
destination becomes active anew. As the CWND towards the original destination becomes active anew. As the CWND towards the original
primary destination has to be rebuilt once data transfer resumes, the primary destination has to be rebuilt once data transfer resumes, the
switch back to use the original primary path is not always optimal. switch back to use the original primary path is not always optimal.
Indeed [CARO02] shows that the switch over to the original primary Indeed [CARO02] shows that the switch back to the original primary
may degrade SCTP performance compared to continuing data transmission may degrade SCTP performance compared to continuing data transmission
on the same path, especially, but not only, in scenarios where this on the same path, especially, but not only, in scenarios where this
path's characteristics are better. In order to mitigate this path's characteristics are better. In order to mitigate this
performance degradation, Permanent Failover operation was proposed in performance degradation, Permanent Failover operation was proposed in
[CARO02]. When SCTP changes the destination due to failover, [CARO02]. When SCTP changes the destination due to failover,
Permanent Failover marks it as new primary. This means Permanent Permanent Failover operation allows SCTP sender to continue data
Failover allows SCTP sender to continue data transmission to the path transmission on the new working path even if the old primary
even after the old primary destination becomes active again. This is destination becomes active again. This is achieved by having SCTP
achieved by having SCTP perform a switchover of the primary path to perform a switch over of the primary path to the alternative working
an alternative working path rather than having SCTP switch back data path rather than having SCTP switch back data transfer to the
transfer to the (previous) primary path. (previous) primary path.
The manner of switchover operation that is most optimal in a given The manner of switch over operation that is most optimal in a given
scenario depends on the relative quality of a set primary path versus scenario depends on the relative quality of a set primary path versus
the quality of alternative paths available as well as it depends on the quality of alternative paths available as well as it depends on
the extent to which it is desired for the mode of operation to the extent to which it is desired for the mode of operation to
enforce traffic distribution over a number of network paths. I.e., enforce traffic distribution over a number of network paths. I.e.,
load distribution of traffic from multiple SCTP associations may be load distribution of traffic from multiple SCTP associations may be
sought to be enforced by distribution of the set primary paths with sought to be enforced by distribution of the set primary paths with
[RFC4960] switchback operation. However as [RFC4960] switchback [RFC4960] switchback operation. However as [RFC4960] switchback
behavior is suboptimal in certain situations, especially in scenarios behavior is suboptimal in certain situations, especially in scenarios
where a number of equally good paths are available, it is recommended where a number of equally good paths are available, it is recommended
for SCTP to support also, as alternative behavior, the Permanent for SCTP to support also, as alternative behavior, the Permanent
Failover modes of operation where forced switch back to a previously Failover switch over modes of operation.
failed primary path is not always performed. The Permanent Failover
operation requires only sender side changes. Details, as originally The Permanent Failover operation requires only sender side changes.
outlined in [CARO02], are: The details are:
1. The sender maintains a new tunable parameter, called 1. The sender maintains a new tunable parameter, called
Primary.Switchover.Max.Retrans (PSMR). When the path error Primary.Switchover.Max.Retrans (PSMR). The PSMR SHOULD be set
counter on a set primary path exceeds PSMR, the SCTP greater or equal to the PFMR value. Any setting of PSMR < PFMR
implementation autonomously selects and sets a new primary path. MUST be rejected by the implementation.
2. The primary path selected by the SCTP implementation shall be the 2. When the path error counter on a set primary path exceeds PSMR,
the SCTP implementation autonomously selects and sets a new
primary path.
3. The primary path selected by the SCTP implementation shall be the
path which at the given time would be chosen for data transfer. path which at the given time would be chosen for data transfer.
A previously failed primary path may come in use as data transfer A previously failed primary path may come in use as data transfer
path as per normal path selection when the present data transfer path as per normal path selection when the present data transfer
path fails. path fails.
3. The recommended value of PSMR is PFMR when Permanent failover is 4. The recommended value of PSMR is PFMR when Permanent Failover is
used. This means that no forced switchback to a previously used. This means that no forced switchback to a previously
failed primary path is performed. failed primary path is performed. An implementation of Permanent
Failover MUST support set of PSMR = PFMR. An implementation of
Permanent Failover MAY support setting of PSMR > PFMR.
4. It must be possible to disable the Permanent Failover and obtain 5. It MUST be possible to disable the Permanent Failover and obtain
the standard switchback operation of [RFC4960]. the standard switchback operation of [RFC4960].
We recommend that SCTP-PF should stick to the standard RFC4960 We recommend that SCTP-PF sticks to the standard RFC4960 switchback
behavior as default, i.e., switch back to the old primary destination behavior as default, i.e., switch back to the old primary destination
once the destination becomes active again. However, implementors MAY once the destination becomes active again. However in order to
implement Permanent Failover and MAY enable it based on network support optimal operation in a wider range of network scenarios, an
configurations or users' requests. implementation MAY implement Permanent Failover operation as detailed
above and MAY enable it based on network configurations or users'
requests.
6. Socket API Considerations 5. Socket API Considerations
This section describes how the socket API defined in [RFC6458] is This section describes how the socket API defined in [RFC6458] is
extended to provide a way for the application to control and observe extended to provide a way for the application to control and observe
the quick failover behavior. the quick failover behavior.
Please note that this section is informational only. Please note that this section is informational only.
A socket API implementation based on [RFC6458] is, by means of the A socket API implementation based on [RFC6458] is, by means of the
existing SCTP_PEER_ADDR_CHANGE event, extended to provide the event existing SCTP_PEER_ADDR_CHANGE event, extended to provide the event
notification when a peer address enters or leaves the potentially notification when a peer address enters or leaves the potentially
failed state as well as the socket API implementation is extended to failed state as well as the socket API implementation is extended to
expose the potentially failed state of a peer address in the existing expose the potentially failed state of a peer address in the existing
SCTP_GET_PEER_ADDR_INFO structure. SCTP_GET_PEER_ADDR_INFO structure.
Furthermore, two new read/write socket options for the level Furthermore, two new read/write socket options for the level
IPPROTO_SCTP and the name SCTP_PEER_ADDR_THLDS and IPPROTO_SCTP and the name SCTP_PEER_ADDR_THLDS and
SCTP_EXPOSE_POTENTIALLY_FAILED_STATE are defined as described below. SCTP_EXPOSE_POTENTIALLY_FAILED_STATE are defined as described below.
The first socket option is used to control the values of the PFMR and The first socket option is used to control the values of the PFMR and
PSMR parameters described in Section 5. The second one controls the PSMR parameters described in Section 4. The second one controls the
exposition of the potentially failed path state. exposition of the potentially failed path state.
Support for the SCTP_PEER_ADDR_THLDS and Support for the SCTP_PEER_ADDR_THLDS and
SCTP_EXPOSE_POTENTIALLY_FAILED_STATE socket options need also to be SCTP_EXPOSE_POTENTIALLY_FAILED_STATE socket options need also to be
added to the function sctp_opt_info(). added to the function sctp_opt_info().
6.1. Support for the Potentially Failed Path State 5.1. Support for the Potentially Failed Path State
As defined in [RFC6458], the SCTP_PEER_ADDR_CHANGE event is provided As defined in [RFC6458], the SCTP_PEER_ADDR_CHANGE event is provided
if the status of a peer address changes. In addition to the state if the status of a peer address changes. In addition to the state
changes described in [RFC6458], this event is also provided, if a changes described in [RFC6458], this event is also provided, if a
peer address enters or leaves the potentially failed state. The peer address enters or leaves the potentially failed state. The
notification as defined in [RFC6458] uses the following structure: notification as defined in [RFC6458] uses the following structure:
struct sctp_paddr_change { struct sctp_paddr_change {
uint16_t spc_type; uint16_t spc_type;
uint16_t spc_flags; uint16_t spc_flags;
skipping to change at page 13, line 27 skipping to change at page 12, line 21
uint32_t spinfo_rto; uint32_t spinfo_rto;
uint32_t spinfo_mtu; uint32_t spinfo_mtu;
}; };
[RFC6458] defines the constants SCTP_UNCONFIRMED, SCTP_ACTIVE, and [RFC6458] defines the constants SCTP_UNCONFIRMED, SCTP_ACTIVE, and
SCTP_INACTIVE to be provided in the spinfo_state field. This SCTP_INACTIVE to be provided in the spinfo_state field. This
document defines in addition to that the new constant document defines in addition to that the new constant
SCTP_POTENTIALLY_FAILED, which is reported if the peer address is SCTP_POTENTIALLY_FAILED, which is reported if the peer address is
potentially failed. potentially failed.
6.2. Peer Address Thresholds (SCTP_PEER_ADDR_THLDS) Socket Option 5.2. Peer Address Thresholds (SCTP_PEER_ADDR_THLDS) Socket Option
Applications can control the quick failover behavior by getting or Applications can control the quick failover behavior by getting or
setting the number of consecutive timeouts before a peer address is setting the number of consecutive timeouts before a peer address is
considered potentially failed or unreachable and before the primary considered potentially failed or unreachable and before the primary
path is changed automatically. This socket option uses the level path is changed automatically. This socket option uses the level
IPPROTO_SCTP and the name SCTP_PEER_ADDR_THLDS. IPPROTO_SCTP and the name SCTP_PEER_ADDR_THLDS.
The following structure is used to access and modify the thresholds: The following structure is used to access and modify the thresholds:
struct sctp_paddrthlds { struct sctp_paddrthlds {
skipping to change at page 14, line 22 skipping to change at page 13, line 15
spt_pathpfthld: Each peer address of interest is considered spt_pathpfthld: Each peer address of interest is considered
potentially failed, if its path error counter exceeds potentially failed, if its path error counter exceeds
spt_pathpfthld. spt_pathpfthld.
spt_pathcpthld: Each peer address of interest is not considered the spt_pathcpthld: Each peer address of interest is not considered the
primary remote address anymore, if its path error counter exceeds primary remote address anymore, if its path error counter exceeds
spt_pathcpthld. Using a value of 0xffff disables the selection of spt_pathcpthld. Using a value of 0xffff disables the selection of
a new primary peer address. If an implementation does not support a new primary peer address. If an implementation does not support
the automatically selection of a new primary address, it should the automatically selection of a new primary address, it should
indicate an error with errno set to EINVAL if a value different indicate an error with errno set to EINVAL if a value different
from 0xffff is used in spt_pathcpthld. from 0xffff is used in spt_pathcpthld. Setting of spt_pathcpthld
< spt_pathpfthld should be rejected with errno set to EINVAL. An
implementation MAY support only setting of spt_pathcpthld =
spt_pathpfthld and spt_pathcpthld = 0xffff. In this case it shall
reject setting of other values with errno set to EINVAL.
6.3. Exposing the Potentially Failed Path State 5.3. Exposing the Potentially Failed Path State
(SCTP_EXPOSE_POTENTIALLY_FAILED_STATE) Socket Option (SCTP_EXPOSE_POTENTIALLY_FAILED_STATE) Socket Option
Applications can control the exposure of the potentially failed path Applications can control the exposure of the potentially failed path
state in the SCTP_PEER_ADDR_CHANGE event and the state in the SCTP_PEER_ADDR_CHANGE event and the
SCTP_GET_PEER_ADDR_INFO as described in Section 6.1. The default SCTP_GET_PEER_ADDR_INFO as described in Section 5.1. The default
value is implementation specific. value is implementation specific.
This socket option uses the level IPPROTO_SCTP and the name This socket option uses the level IPPROTO_SCTP and the name
SCTP_EXPOSE_POTENTIALLY_FAILED_STATE. SCTP_EXPOSE_POTENTIALLY_FAILED_STATE.
The following structure is used to control the exposition of the The following structure is used to control the exposition of the
potentially failed path state: potentially failed path state:
struct sctp_assoc_value { struct sctp_assoc_value {
sctp_assoc_t assoc_id; sctp_assoc_t assoc_id;
skipping to change at page 15, line 5 skipping to change at page 13, line 48
}; };
assoc_id: This parameter is ignored for one-to-one style sockets. assoc_id: This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets the application may fill in an For one-to-many style sockets the application may fill in an
association identifier or SCTP_FUTURE_ASSOC. It is an error to association identifier or SCTP_FUTURE_ASSOC. It is an error to
use SCTP_{CURRENT|ALL}_ASSOC in assoc_id. use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.
assoc_value: The potentially failed path state is exposed if and assoc_value: The potentially failed path state is exposed if and
only if this parameter is non-zero. only if this parameter is non-zero.
7. Security Considerations 6. Security Considerations
There are no new security considerations introduced in this document. There are no new security considerations introduced in this document.
8. IANA Considerations 7. IANA Considerations
This document does not create any new registries or modify the rules This document does not create any new registries or modify the rules
for any existing registries managed by IANA. for any existing registries managed by IANA.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
RFC 4960, September 2007. 4960, September 2007.
9.2. Informative References 8.2. Informative References
[CARO02] Caro Jr., A., Iyengar, J., Amer, P., Heinz, G., and R. [CARO02] Caro Jr., A., Iyengar, J., Amer, P., Heinz, G., and R.
Stewart, "A Two-level Threshold Recovery Mechanism for Stewart, "A Two-level Threshold Recovery Mechanism for
SCTP", Tech report, CIS Dept, University of Delaware , SCTP", Tech report, CIS Dept, University of Delaware , 7
7 2002. 2002.
[CARO04] Caro Jr., A., Amer, P., and R. Stewart, "End-to-End [CARO04] Caro Jr., A., Amer, P., and R. Stewart, "End-to-End
Failover Thresholds for Transport Layer Multihoming", Failover Thresholds for Transport Layer Multihoming",
MILCOM 2004 , 11 2004. MILCOM 2004 , 11 2004.
[CARO05] Caro Jr., A., "End-to-End Fault Tolerance using Transport [CARO05] Caro Jr., A., "End-to-End Fault Tolerance using Transport
Layer Multihoming", Ph.D Thesis, University of Delaware , Layer Multihoming", Ph.D Thesis, University of Delaware ,
1 2005. 1 2005.
[FALLON08] [FALLON08]
skipping to change at page 17, line 43 skipping to change at page 14, line 48
Environments", IEEE CCNC 2008, 1 2008. Environments", IEEE CCNC 2008, 1 2008.
[GRINNEMO04] [GRINNEMO04]
Grinnemo, K-J. and A. Brunstrom, "Performance of SCTP- Grinnemo, K-J. and A. Brunstrom, "Performance of SCTP-
controlled failovers in M3UA-based SIGTRAN networks", controlled failovers in M3UA-based SIGTRAN networks",
Advanced Simulation Technologies Conference , 4 2004. Advanced Simulation Technologies Conference , 4 2004.
[IYENGAR06] [IYENGAR06]
Iyengar, J., Amer, P., and R. Stewart, "Concurrent Iyengar, J., Amer, P., and R. Stewart, "Concurrent
Multipath Transfer using SCTP Multihoming over Independent Multipath Transfer using SCTP Multihoming over Independent
End-to-end Paths.", IEEE/ACM Trans on Networking 14(5), End-to-end Paths.", IEEE/ACM Trans on Networking 14(5), 10
10 2006. 2006.
[JUNGMAIER02] [JUNGMAIER02]
Jungmaier, A., Rathgeb, E., and M. Tuexen, "On the use of Jungmaier, A., Rathgeb, E., and M. Tuexen, "On the use of
SCTP in failover scenarios", World Multiconference on SCTP in failover scenarios", World Multiconference on
Systemics, Cybernetics and Informatics , 7 2002. Systemics, Cybernetics and Informatics , 7 2002.
[NATARAJAN09] [NATARAJAN09]
Natarajan, P., Ekiz, N., Amer, P., and R. Stewart, Natarajan, P., Ekiz, N., Amer, P., and R. Stewart,
"Concurrent Multipath Transfer during Path Failure", "Concurrent Multipath Transfer during Path Failure",
Computer Communications , 5 2009. Computer Communications , 5 2009.
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Yasevich, "Sockets API Extensions for the Stream Control Yasevich, "Sockets API Extensions for the Stream Control
Transmission Protocol (SCTP)", RFC 6458, December 2011. Transmission Protocol (SCTP)", RFC 6458, December 2011.
Appendix A. Discussions of Alternative Approaches
This section lists alternative approaches for the issues desribed in
this document. Although these approaches do not require to update
RFC4960, we do not recommend them from the reasons described below.
A.1. Reduce Path.Max.Retrans (PMR)
Smaller values for Path.Max.Retrans shorten the failover duration.
In fact, this is recommended in some research results [JUNGMAIER02]
[GRINNEMO04] [FALLON08]. For example, if when Path.Max.Retrans=0,
SCTP switches to another destination on a single timeout. This
smaller value for Path.Max.Retrans can results in spurious failover,
which might be a problem.
Unlike SCTP-PF, the interval for heartbeat packets is governed by
'HB.interval' even during failover process. 'HB.interval' is usually
set in the order of seconds (recommended value is 30 seconds). When
the primary path becomes inactive, the next HB can be transmitted
only seconds later. Meanwhile, the primary path may have recovered.
In such situations, post failover, an endpoint is forced to wait on
the order of seconds before the endpoint can resume transmission on
the primary path. However, using smaller value for 'HB.interval'
might help this situation, but it will be the waste of bandwidth in
most cases.
In addition, smaller Path.Max.Retrans values also affect
'Association.Max.Retrans' values. When the SCTP association's error
count (sum of error counts on all ACTIVE paths) exceeds
Association.Max.Retrans threshold, the SCTP sender considers the peer
endpoint unreachable and terminates the association. Therefore,
Section 8.2 in [RFC4960] recommends that Association.Max.Retrans
value should not be larger than the summation of the Path.Max.Retrans
of each of the destination addresses, else the SCTP sender considers
its peer reachable even when all destinations are INACTIVE. To avoid
such inconsistent behavior an SCTP implementation SHOULD reduce
Association.Max.Retrans accordingly whenever it reduces
Path.Max.Retrans. However, smaller Association.Max.Retrans value
increases chances of association termination during minor congestion
events.
A.2. Adjust RTO related parameters
As several research results indicate, we can also shorten the
duration of failover process by adjusting RTO related parameters
[JUNGMAIER02] [FALLON08]. During failover process, RTO keeps being
doubled. However, if we can choose smaller value for RTO.max, we can
stop the exponential growth of RTO at some point. Also, choosing
smaller values for RTO.initial or RTO.min can contribute to keep RTO
value small.
Similar to reducing Path.Max.Retrans, the advantage of this approach
is that it requires no modification to the current specification,
although it needs to ignore several recommendations described in the
Section 15 of [RFC4960]. However, this approach requires to have
enough knowledge about the network characteristics between end
points. Otherwise, it can introduce adverse side-effects such as
spurious timeouts.
Appendix B. Discussions for Path Bouncing Effect
The methods described in the document can accelerate the failover
process. Hence, they might introduce the path bouncing effect where
the sender keeps changing the data transmission path frequently.
This sounds harmful to the data transfer, however several research
results indicate that there is no serious problem with SCTP in terms
of path bouncing effect [CARO04] [CARO05].
There are two main reasons for this. First, SCTP is basically
designed for multipath communication, which means SCTP maintains all
path related parameters (CWND, ssthresh, RTT, error count, etc) per
each destination address. These parameters cannot be affected by
path bouncing. In addition, when SCTP migrates the data transfer to
another path, it starts with the minimal or the initial CWND. Hence,
there is little chance for packet reordering or duplicating.
Second, even if all communication paths between the end-nodes share
the same bottleneck, the quick failover results in a behavior already
allowed by [RFC4960].
Authors' Addresses Authors' Addresses
Yoshifumi Nishida Yoshifumi Nishida
GE Global Research GE Global Research
2623 Camino Ramon 2623 Camino Ramon
San Ramon, CA 94583 San Ramon, CA 94583
USA USA
Email: nishida@wide.ad.jp Email: nishida@wide.ad.jp
skipping to change at page 19, line 42 skipping to change at page 17, line 42
University of Delaware University of Delaware
Computer Science Department - 434 Smith Hall Computer Science Department - 434 Smith Hall
Newark, DE 19716-2586 Newark, DE 19716-2586
USA USA
Email: amer@udel.edu Email: amer@udel.edu
Karen E. E. Nielsen Karen E. E. Nielsen
Ericsson Ericsson
Kistavaegen 25 Kistavaegen 25
Stockholm, 164 80 Stockholm 164 80
Sweden Sweden
Email: karen.nielsen@tieto.com Email: karen.nielsen@tieto.com
 End of changes. 59 change blocks. 
234 lines changed or deleted 360 lines changed or added

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