draft-ietf-tsvwg-sctp-failover-14.txt   draft-ietf-tsvwg-sctp-failover-15.txt 
Network Working Group Y. Nishida Network Working Group Y. Nishida
Internet-Draft GE Global Research Internet-Draft GE Global Research
Intended status: Standards Track P. Natarajan Intended status: Standards Track P. Natarajan
Expires: June 11, 2016 Cisco Systems Expires: July 28, 2016 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
December 9, 2015 January 25, 2016
SCTP-PF: Quick Failover Algorithm in SCTP SCTP-PF: Quick Failover Algorithm in SCTP
draft-ietf-tsvwg-sctp-failover-14.txt draft-ietf-tsvwg-sctp-failover-15.txt
Abstract Abstract
SCTP supports multi-homing. However, when the failover operation SCTP supports multi-homing. However, when the failover operation
specified in RFC4960 is followed, there can be significant delay and specified in RFC4960 is followed, there can be significant delay and
performance degradation in the data transfer path failover. To performance degradation in the data transfer path failover. To
overcome this problem this document specifies a quick failover overcome this problem this document specifies a quick failover
algorithm (SCTP-PF) based on the introduction of a Potentially Failed algorithm (SCTP-PF) based on the introduction of a Potentially Failed
(PF) state in SCTP Path Management. (PF) state in SCTP Path Management.
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 June 11, 2016. This Internet-Draft will expire on July 28, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
skipping to change at page 2, line 38 skipping to change at page 2, line 38
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. SCTP with Potentially Failed Destination State (SCTP-PF) . . 4 3. SCTP with Potentially Failed Destination State (SCTP-PF) . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Specification of the SCTP-PF Procedures . . . . . . . . . 5 3.2. Specification of the SCTP-PF Procedures . . . . . . . . . 5
4. Dormant State Operation . . . . . . . . . . . . . . . . . . . 9 4. Dormant State Operation . . . . . . . . . . . . . . . . . . . 9
4.1. SCTP Dormant State Procedure . . . . . . . . . . . . . . 10 4.1. SCTP Dormant State Procedure . . . . . . . . . . . . . . 10
5. Primary Path Switchover . . . . . . . . . . . . . . . . . . . 11 5. Primary Path Switchover . . . . . . . . . . . . . . . . . . . 10
6. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 12 6. Suggested SCTP Protocol Parameter Values . . . . . . . . . . 12
7. Socket API Considerations . . . . . . . . . . . . . . . . . . 12 7. Socket API Considerations . . . . . . . . . . . . . . . . . . 12
7.1. Support for the Potentially Failed Path State . . . . . . 13 7.1. Support for the Potentially Failed Path State . . . . . . 13
7.2. Peer Address Thresholds (SCTP_PEER_ADDR_THLDS) Socket 7.2. Peer Address Thresholds (SCTP_PEER_ADDR_THLDS) Socket
Option . . . . . . . . . . . . . . . . . . . . . . . . . 14 Option . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Exposing the Potentially Failed Path State 7.3. Exposing the Potentially Failed Path State
(SCTP_EXPOSE_POTENTIALLY_FAILED_STATE) Socket Option . . 15 (SCTP_EXPOSE_POTENTIALLY_FAILED_STATE) Socket Option . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. Proposed Change of Status (to be Deleted before Publication) 17 11. Proposed Change of Status (to be Deleted before Publication) 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Discussions of Alternative Approaches . . . . . . . 18 Appendix A. Discussions of Alternative Approaches . . . . . . . 18
A.1. Reduce Path.Max.Retrans (PMR) . . . . . . . . . . . . . . 18 A.1. Reduce Path.Max.Retrans (PMR) . . . . . . . . . . . . . . 18
A.2. Adjust RTO related parameters . . . . . . . . . . . . . . 19 A.2. Adjust RTO related parameters . . . . . . . . . . . . . . 19
Appendix B. Discussions for Path Bouncing Effect . . . . . . . . 20 Appendix B. Discussions for Path Bouncing Effect . . . . . . . . 19
Appendix C. SCTP-PF for SCTP Single-homed Operation . . . . . . 20 Appendix C. SCTP-PF for SCTP Single-homed Operation . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The Stream Control Transmission Protocol (SCTP) specified in The Stream Control Transmission Protocol (SCTP) specified in
[RFC4960] supports multi-homing at the transport layer. SCTP's [RFC4960] supports multi-homing at the transport layer. SCTP's
multi-homing features include failure detection and failover multi-homing 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. In SCTP's current failure detection to-end fault tolerance. In SCTP's current failure detection
procedure, the sender must experience Path.Max.Retrans (PMR) number procedure, the sender must experience Path.Max.Retrans (PMR) number
of consecutive failed timer-based retransmissions on a destination of consecutive failed timer-based retransmissions on a destination
skipping to change at page 4, line 51 skipping to change at page 4, line 51
stops transmitting data to a destination address only after the stops transmitting data to a destination address only after the
destination address is marked inactive. This process takes a destination address is marked inactive. This process takes a
significant amount of time as it requires the error counter of the significant amount of time as it requires the error counter of the
destination address to exceed the Path.Max.Retrans (PMR) threshold. destination address to exceed the Path.Max.Retrans (PMR) threshold.
The issue cannot simply be mitigated by lowering of the PMR threshold The issue cannot simply be mitigated by lowering of the PMR threshold
because this may result in spurious failure detection and unnecessary because this may result in spurious failure detection and unnecessary
prevention of the usage of a preferred primary path. Also due to the prevention of the usage of a preferred primary path. Also due to the
coupled tuning of the Path.Max.Retrans (PMR) and the coupled tuning of the Path.Max.Retrans (PMR) and the
Association.Max.Retrans (AMR) parameter values in [RFC4960], lowering Association.Max.Retrans (AMR) parameter values in [RFC4960], lowering
of the PMR threshold may result in lowering of the AMR threshold, of the PMR threshold may result in lowering of the AMR threshold,
which may result in compromisation of the fault tolerance of SCTP. which would result in decrease of the fault tolerance of SCTP.
The solution provided in this document is to extend the SCTP path The solution provided in this document is to extend the SCTP path
management scheme of [RFC4960] by the addition of the Potentially management scheme of [RFC4960] by the addition of the Potentially
Failed (PF) state as an intermediate state in between the active and Failed (PF) state as an intermediate state in between the active and
inactive state of a destination address in the [RFC4960] path inactive state of a destination address in the [RFC4960] path
management scheme, and let the failover of data transfer away from a management scheme, and let the failover of data transfer away from a
destination address be driven by the entering of the PF state instead destination address be driven by the entering of the PF state instead
of by the entering of the inactive state. Thereby SCTP may perform of by the entering of the inactive state. Thereby SCTP may perform
quick failover without compromising the overall fault tolerance of quick failover without negatively impacting the overall fault
[RFC4960] SCTP. At the same time, RTO-based HEARTBEAT probing is tolerance of [RFC4960] SCTP. At the same time, RTO-based HEARTBEAT
initiated towards a destination address once it enters PF state. probing is initiated towards a destination address once it enters PF
Thereby SCTP may quickly ascertain whether network connectivity state. Thereby SCTP may quickly ascertain whether network
towards the destination address is broken or whether the failover was connectivity towards the destination address is broken or whether the
spurious. In the case where the failover was spurious data transfer failover was spurious. In the case where the failover was spurious
may quickly resume towards the original destination address. data transfer may quickly resume towards the original destination
address.
The new failure detection algorithm assumes that loss detected by a The new failure detection algorithm assumes that loss detected by a
timeout implies either severe congestion or network connectivity timeout implies either severe congestion or network connectivity
failure. It recommends that by default a destination address is failure. It recommends that by default a destination address is
classified as PF at the occurrence of the first timeout. classified as PF at the occurrence of the first timeout.
3.2. Specification of the SCTP-PF Procedures 3.2. Specification of the SCTP-PF Procedures
The SCTP-PF operation is specified as follows: The SCTP-PF operation is specified as follows:
1. The sender maintains a new tunable SCTP Protocol Parameter 1. The sender maintains a new tunable SCTP Protocol Parameter
called PotentiallyFailed.Max.Retrans (PFMR). The PFMR defines called PotentiallyFailed.Max.Retrans (PFMR). The PFMR defines
the new intermediate PF threshold on the destination address the new intermediate PF threshold on the destination address
error counter at exceed of which the destination address is error counter. When this threshold is exceeded the destination
classified as PF. The RECOMMENDED value of PFMR is 0, but other address is classified as PF. The RECOMMENDED value of PFMR is
values MAY be used. If PFMR is set to be greater than or equal 0, but other values MAY be used. If PFMR is set to be greater
to Path.Max.Retrans (PMR), the resulting PF threshold will be so than or equal to Path.Max.Retrans (PMR), the resulting PF
high that the destination address will reach the inactive state threshold will be so high that the destination address will
before it can be classified as PF. reach the inactive state before it can be classified as PF.
2. The error counter of an active destination address is 2. The error counter of an active destination address is
incremented as specified in [RFC4960]. This means that the incremented as specified in [RFC4960]. This means that the
error counter of the destination address will be incremented error counter of the destination address will be incremented
each time the T3-rtx timer expires, or each time a HEARTBEAT each time the T3-rtx timer expires, or each time a HEARTBEAT
chunk is sent when idle and not acknowledged within an RTO. chunk is sent when idle and not acknowledged within an RTO.
When the value in the destination address error counter exceeds When the value in the destination address error counter exceeds
PFMR, the endpoint MUST mark the destination address as in the PFMR, the endpoint MUST mark the destination address as in the
PF state. PF state.
3. A SCTP-PF sender SHOULD NOT send data to destination addresses 3. A SCTP-PF sender SHOULD NOT send data to destination addresses
in PF state when alternative destination addresses in active in PF state when alternative destination addresses in active
state are available. Specifically this means that: state are available. Specifically this means that:
i When there is outbound data to send and the destination i When there is outbound data to send and the destination
address presently used for data transmission is in PF state, address presently used for data transmission is in PF state,
the sender SHOULD choose a destination address in active the sender SHOULD choose a destination address in active
state, if one exists, and failover to deploy this destination state, if one exists, and use this destination address for
address for data transmission. data transmission.
ii When retransmitting data that has timed out and the sender ii When retransmitting data that has timed out and the sender
thus by [RFC4960], section 6.4.1, should attempt to pick a thus by [RFC4960], section 6.4.1, should attempt to pick a
new destination address for data retransmission, the sender new destination address for data retransmission, the sender
SHOULD choose an alternate destination transport address in SHOULD choose an alternate destination transport address in
active state if one exists. active state if one exists.
iii When there is outbound data to send and the SCTP user iii When there is outbound data to send and the SCTP user
explicitly requests to send data to a destination address in explicitly requests to send data to a destination address in
PF state, the sender SHOULD send the data to an alternate PF state, the sender SHOULD send the data to an alternate
destination address in active state if one exists. destination address in active state if one exists.
When choosing among multiple destination addresses in active When choosing among multiple destination addresses in active
state the following considerations are given: state an SCTP sender will follow the guiding principles of
section 6.4.1 of [RFC4960] of choosing most divergent source-
A. An SCTP sender should comply with [RFC4960], section 6.4.1, destination pairs compared with, for i.: the destination address
principles of choosing most divergent source-destination in PF state that it performs a failover from, and for ii.: the
pairs compared with, for i.: the destination address in PF destination address towards which the data timed out. Rules for
state that it performs a failover from, and for ii.: the picking the most divergent source-destination pair are an
destination address towards which the data timed out. Rules implementation decision and are not specified within this
for picking the most divergent source-destination pair are document.
an implementation decision and are not specified within this
document.
B. A SCTP-PF sender MAY choose to send data to a destination
address in PF state, even if destination addresses in active
state exist, have the SCTP-PF sender other means of
information available that disqualifies the destination
address in active state from being preferred. However, the
discussion of such mechanisms is outside of the scope of the
SCTP-PF operation specified in this document.
In all cases, the sender MUST NOT change the state of chosen In all cases, the sender MUST NOT change the state of chosen
destination address, whether this state be active or PF, and it destination address, whether this state be active or PF, and it
MUST NOT clear the error counter of the destination address as a MUST NOT clear the error counter of the destination address as a
result of choosing the destination address for data result of choosing the destination address for data
transmission. transmission.
4. When the destination addresses are all in PF state or some in PF 4. When the destination addresses are all in PF state or some in PF
state and some in inactive state, the sender MUST choose one state and some in inactive state, the sender MUST choose one
destination address in PF state and transmit or retransmit data destination address in PF state and transmit or retransmit data
skipping to change at page 7, line 20 skipping to change at page 7, line 9
B. When there are multiple destination addresses in PF state B. When there are multiple destination addresses in PF state
with same error count, the sender should let the choice with same error count, the sender should let the choice
among the multiple destination addresses in PF state with among the multiple destination addresses in PF state with
equal error count be based on the [RFC4960], section 6.4.1, equal error count be based on the [RFC4960], section 6.4.1,
principles of choosing most divergent source-destination principles of choosing most divergent source-destination
pairs when executing (potentially consecutive) pairs when executing (potentially consecutive)
retransmission. Rules for picking the most divergent retransmission. Rules for picking the most divergent
source-destination pair are an implementation decision and source-destination pair are an implementation decision and
are not specified within this document. are not specified within this document.
C. A sender MAY choose to deploy other strategies than the
above when choosing among multiple destinations in PF state
have the SCTP-PF sender other means of information available
that qualifies a particular destination address for being
used. The SCTP-PF protocol operation specified in this
document makes no assumption of the existence of such other
means of information and specifies for the above as the
default operation of an SCTP-PF sender.
The sender MUST NOT change the state and the error counter of The sender MUST NOT change the state and the error counter of
any destination address regardless of whether it has been chosen any destination address regardless of whether it has been chosen
for transmission or not. for transmission or not.
5. The HB.interval of the Path Heartbeat function of [RFC4960] MUST 5. The HB.interval of the Path Heartbeat function of [RFC4960] MUST
be ignored for destination addresses in PF state. Instead be ignored for destination addresses in PF state. Instead
HEARTBEAT chunks are sent to destination addresses in PF state HEARTBEAT chunks are sent to destination addresses in PF state
once per RTO. HEARTBEAT chunks SHOULD be sent to destination once per RTO. HEARTBEAT chunks SHOULD be sent to destination
addresses in PF state, but the sending of HEARTBEATS MUST honor addresses in PF state, but the sending of HEARTBEATS MUST honor
whether the Path Heartbeat function (Section 8.3 of [RFC4960]) whether the Path Heartbeat function (Section 8.3 of [RFC4960])
skipping to change at page 8, line 40 skipping to change at page 8, line 21
about this state transition, and (ii) transmit HEARTBEAT chunks about this state transition, and (ii) transmit HEARTBEAT chunks
to the inactive destination address at a lower HB.interval to the inactive destination address at a lower HB.interval
frequency as described in Section 8.3 of [RFC4960] (when the frequency as described in Section 8.3 of [RFC4960] (when the
Path Heartbeat function is enabled for the destination address). Path Heartbeat function is enabled for the destination address).
9. Acknowledgments for chunks that have been transmitted to 9. Acknowledgments for chunks that have been transmitted to
multiple destinations (i.e., a chunk which has been multiple destinations (i.e., a chunk which has been
retransmitted to a different destination address than the retransmitted to a different destination address than the
destination address to which the chunk was first transmitted) destination address to which the chunk was first transmitted)
SHOULD NOT clear the error count for an inactive destination SHOULD NOT clear the error count for an inactive destination
address and SHOULD NOT transition a destination address in PF address and SHOULD NOT move a destination address in PF state
state back to active state, since a sender cannot disambiguate back to active state, since a sender cannot disambiguate whether
whether the ACK was for the original transmission or the the ACK was for the original transmission or the
retransmission(s). A SCTP sender MAY apply a different approach retransmission(s). A SCTP sender MAY clear the error counter
for the error count handling based on unequivocally information and move a destination address back to active state if it has
on which destination (including multiple destination addresses) other information, than the acknowledgment, that uniquely
the chunk reached. This document makes no reference to what determines which destination, among multiple destination
such unequivocally information could consist of, nor how such addresses, the chunk reached. This document makes no reference
unequivocally information could be obtained. The design of such to what such information could consist of, nor how such
an alternative approach is left to implementations. information could be obtained.
10. Acknowledgments for data chunks that has been transmitted to one 10. Acknowledgments for data chunks that has been transmitted to one
destination address only MUST clear the error counter for the destination address only MUST clear the error counter for the
destination address and MUST transition a destination address in destination address and MUST transition a destination address in
PF state back to active state. This situation can happen when PF state back to active state. This situation can happen when
new data is sent to a destination address in the PF state. It new data is sent to a destination address in the PF state. It
can also happen in situations where the destination address is can also happen in situations where the destination address is
in the PF state due to the occurrence of a spurious T3-rtx timer in the PF state due to the occurrence of a spurious T3-rtx timer
and acknowledgments start to arrive for data sent prior to and acknowledgments start to arrive for data sent prior to
occurrence of the spurious T3-rtx and data has not yet been occurrence of the spurious T3-rtx and data has not yet been
skipping to change at page 10, line 14 skipping to change at page 9, line 43
multiple destinations addresses in PF state. This argument presumes multiple destinations addresses in PF state. This argument presumes
that RTO << HB.interval of [RFC4960]. With the design goal that that RTO << HB.interval of [RFC4960]. With the design goal that
SCTP-PF shall provide the same level of disruption tolerance as an SCTP-PF shall provide the same level of disruption tolerance as an
[RFC4960] SCTP implementation with the same Path.Max.Retrans (PMR) [RFC4960] SCTP implementation with the same Path.Max.Retrans (PMR)
and Association.Max.Retrans (AMR) setting, we prescribe for that an and Association.Max.Retrans (AMR) setting, we prescribe for that an
SCTP-PF implementation SHOULD operate as described below in SCTP-PF implementation SHOULD operate as described below in
Section 4.1 during dormant state. Section 4.1 during dormant state.
An SCTP-PF implementation MAY choose a different dormant state An SCTP-PF implementation MAY choose a different dormant state
operation than the one described below in Section 4.1 provided that operation than the one described below in Section 4.1 provided that
the solution chosen does not compromise the fault tolerance of the the solution chosen does not decrease the fault tolerance of the
SCTP-PF operation. SCTP-PF operation.
The below prescription for SCTP-PF dormant state handling SHOULD NOT The below prescription for SCTP-PF dormant state handling SHOULD NOT
be coupled to the value of the PFMR, but solely to the activation of be coupled to the value of the PFMR, but solely to the activation of
SCTP-PF logic in an SCTP implementation. SCTP-PF logic in an SCTP implementation.
It is noted that the below dormant state operation is considered to It is noted that the below dormant state operation is considered to
provide added disruption tolerance also for an [RFC4960] SCTP provide added disruption tolerance also for an [RFC4960] SCTP
implementation, and that it can be sensible for an [RFC4960] SCTP implementation, and that it can be sensible for an [RFC4960] SCTP
implementation to follow this mode of operation. For an [RFC4960] implementation to follow this mode of operation. For an [RFC4960]
skipping to change at page 12, line 30 skipping to change at page 12, line 10
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 on the extent the quality of alternative paths available as well as on the extent
to which it is desired for the mode of operation to enforce traffic to which it is desired for the mode of operation to enforce traffic
distribution over a number of network paths. I.e., load distribution distribution over a number of network paths. I.e., load distribution
of traffic from multiple SCTP associations may be sought to be of traffic from multiple SCTP associations may be sought to be
enforced by distribution of the set primary paths with [RFC4960] enforced by distribution of the set primary paths with [RFC4960]
switchback operation. However as [RFC4960] switchback behavior is switchback operation. However as [RFC4960] switchback behavior is
suboptimal in certain situations, especially in scenarios where a suboptimal in certain situations, especially in scenarios where a
number of equally good paths are available, an SCTP implementation number of equally good paths are available, an SCTP implementation
MAY support also, as alternative behavior, the Primary Path MAY support also, as alternative behavior, the Primary Path
Switchover mode of operation and MAY enable it based on users' Switchover mode of operation and MAY enable it based on applications'
requests. requests.
For an SCTP implementation that implements the Primary Path For an SCTP implementation that implements the Primary Path
Switchover operation, this specification RECOMMENDS that the standard Switchover operation, this specification RECOMMENDS that the standard
RFC4960 switchback operation is retained as the default operation. RFC4960 switchback operation is retained as the default operation.
6. Suggested SCTP Protocol Parameter Values 6. Suggested SCTP Protocol Parameter Values
This document does not alter the [RFC4960] value RECOMMENDATIONS for This document does not alter the [RFC4960] value RECOMMENDATIONS for
the SCTP Protocol Parameters defined in [RFC4960]. the SCTP Protocol Parameters defined in [RFC4960].
skipping to change at page 16, line 18 skipping to change at page 15, line 48
discussed in [RFC4960] and [RFC6458]. discussed in [RFC4960] and [RFC6458].
The logic introduced by this document does not impact existing SCTP The logic introduced by this document does not impact existing SCTP
messages on the wire. Also, this document does not introduce any new messages on the wire. Also, this document does not introduce any new
SCTP messages on the wire that require new security considerations. SCTP messages on the wire that require new security considerations.
SCTP-PF makes SCTP not only more robust during primary path failure/ SCTP-PF makes SCTP not only more robust during primary path failure/
congestion but also more vulnerable to network connectivity/ congestion but also more vulnerable to network connectivity/
congestion attacks on the primary path. SCTP-PF makes it easier for congestion attacks on the primary path. SCTP-PF makes it easier for
an attacker to trick SCTP to change data transfer path, since the an attacker to trick SCTP to change data transfer path, since the
duration of time that an attacker needs to compromise the network duration of time that an attacker needs to negatively influence the
connectivity is much shorter than [RFC4960]. However, SCTP-PF does network connectivity is much shorter than [RFC4960]. However, SCTP-
not constitute a significant change in the duration of time and PF does not constitute a significant change in the duration of time
effort an attacker needs to keep SCTP away from the primary path. and effort an attacker needs to keep SCTP away from the primary path.
With the standard switchback operation [RFC4960] SCTP resumes data With the standard switchback operation [RFC4960] SCTP resumes data
transfer on its primary path as soon as the next HEARTBEAT succeeds. transfer on its primary path as soon as the next HEARTBEAT succeeds.
On the other hand, usage of the Primary Path Switchover mechanism, On the other hand, usage of the Primary Path Switchover mechanism,
does change the threat analysis. This is because on-path attackers does change the threat analysis. This is because on-path attackers
can force a permanent change of the data transfer path by blocking can force a permanent change of the data transfer path by blocking
the primary path until the switchover of the primary path is the primary path until the switchover of the primary path is
triggered by the Primary Path Switchover algorithm. This especially triggered by the Primary Path Switchover algorithm. This especially
will be the case when the Primary Path Switchover is used together will be the case when the Primary Path Switchover is used together
with SCTP-PF with the particular setting of PSMR = PFMR = 0, as with SCTP-PF with the particular setting of PSMR = PFMR = 0, as
skipping to change at page 17, line 22 skipping to change at page 17, line 4
harmful features, consensus exists in the WG to bring the work harmful features, consensus exists in the WG to bring the work
forward as PS. forward as PS.
Initially concerns have been expressed about the possibility for the Initially concerns have been expressed about the possibility for the
mechanism to introduce path bouncing with potential harmful network mechanism to introduce path bouncing with potential harmful network
impacts. These concerns are believed to be unfounded. This issue is impacts. These concerns are believed to be unfounded. This issue is
addressed in Appendix B. addressed in Appendix B.
It is noted that the feature specified by this document is It is noted that the feature specified by this document is
implemented by multiple SCTP SW implementations and furthermore that implemented by multiple SCTP SW implementations and furthermore that
various variants of the solution have been deployed in Tel co various variants of the solution have been deployed in telephony
signaling environments for several years with good results. signaling environments for several years with good results.
12. References 12. References
12.1. Normative References 12.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, Requirement Levels", BCP 14, RFC 2119, March 1997.
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
RFC 4960, DOI 10.17487/RFC4960, September 2007, 4960, September 2007.
<http://www.rfc-editor.org/info/rfc4960>.
12.2. Informative References 12.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 , 7 SCTP", Tech report, CIS Dept, University of Delaware , 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 Multi homing", Failover Thresholds for Transport Layer Multi homing",
skipping to change at page 18, line 33 skipping to change at page 18, line 12
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, Transmission Protocol (SCTP)", RFC 6458, December 2011.
DOI 10.17487/RFC6458, December 2011,
<http://www.rfc-editor.org/info/rfc6458>.
Appendix A. Discussions of Alternative Approaches Appendix A. Discussions of Alternative Approaches
This section lists alternative approaches for the issues described in This section lists alternative approaches for the issues described in
this document. Although these approaches do not require to update this document. Although these approaches do not require to update
RFC4960, we do not recommend them from the reasons described below. RFC4960, we do not recommend them from the reasons described below.
A.1. Reduce Path.Max.Retrans (PMR) A.1. Reduce Path.Max.Retrans (PMR)
Smaller values for Path.Max.Retrans shorten the failover duration and Smaller values for Path.Max.Retrans shorten the failover duration and
skipping to change at page 19, line 34 skipping to change at page 19, line 11
'Association.Max.Retrans' value. When the SCTP association's error 'Association.Max.Retrans' value. When the SCTP association's error
count exceeds Association.Max.Retrans threshold, the SCTP sender count exceeds Association.Max.Retrans threshold, the SCTP sender
considers the peer endpoint unreachable and terminates the considers the peer endpoint unreachable and terminates the
association. Section 8.2 in [RFC4960] recommends that association. Section 8.2 in [RFC4960] recommends that
Association.Max.Retrans value should not be larger than the summation Association.Max.Retrans value should not be larger than the summation
of the Path.Max.Retrans of each of the destination addresses. Else of the Path.Max.Retrans of each of the destination addresses. Else
the SCTP sender considers its peer reachable even when all the SCTP sender considers its peer reachable even when all
destinations are INACTIVE and to avoid this dormant state operation, destinations are INACTIVE and to avoid this dormant state operation,
[RFC4960] SCTP implementation SHOULD reduce Association.Max.Retrans [RFC4960] SCTP implementation SHOULD reduce Association.Max.Retrans
accordingly whenever it reduces Path.Max.Retrans. However, smaller accordingly whenever it reduces Path.Max.Retrans. However, smaller
Association.Max.Retrans value compromises the fault tolerance of SCTP Association.Max.Retrans value decreases the fault tolerance of SCTP
as it increases the chances of association termination during minor as it increases the chances of association termination during minor
congestion events. congestion events.
A.2. Adjust RTO related parameters A.2. Adjust RTO related parameters
As several research results indicate, we can also shorten the As several research results indicate, we can also shorten the
duration of failover process by adjusting RTO related parameters duration of failover process by adjusting RTO related parameters
[JUNGMAIER02] [FALLON08]. During failover process, RTO keeps being [JUNGMAIER02] [FALLON08]. During failover process, RTO keeps being
doubled. However, if we can choose smaller value for RTO.max, we can doubled. However, if we can choose smaller value for RTO.max, we can
stop the exponential growth of RTO at some point. Also, choosing stop the exponential growth of RTO at some point. Also, choosing
 End of changes. 25 change blocks. 
80 lines changed or deleted 58 lines changed or added

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