Subject: [tsvwg] draft-ietf-tsvwg-sctp-failover: comments and suggestions

From: Salvatore Loreto <[email-masked]>
Date: Mon, 27 May 2013 16:34:31 +0300

Hi there,

Karen (in cc) and I have reviewed together the draft and written down 
the following comments and suggestions

- Section 5.1: CWND Handling for Potentially Failed Destinations

The draft speaks about setting the CWND to 1 MTU (or 2MTU ?) when a 
Potentially Failed Path (destination) is reinstated
in ACTIVE state as a result of the receipt of an HB ACK.

We are not sure what is the motivation for any special measures to be 
taken in this situation.

Generally the CWND settings are governed by RFC4960 prescriptions as to 
set the CWND to 1 MTU after T3-rtx (but not afterHB timeout)
as well as RFC4960 guidelines to converge the CWND to the initial CWND 
towards idle destination addresses.

We believe, in this respect, it is appropriate to keep the standard 
behaviour of RFC4960.

- Section 5.3: Permanent Failover

We have good experiences from live networks with running SCTP in a “no 
switchback” mode of operation with no automatic migration
back to a preferred primary path. Once the primary path is left due to 
it being potentially failed, then a selected alternative path automatically
becomes the new primary path.

This mode of operation corresponds to a simplified variant of the 
permanent failover operation proposed in [CAR002]
with alpha = beta = SCTP_PEER_ADDR:THLDS. The mode of operation is run 
with notifications of change of primary path being provided
to upper layers via RFC6458 SCTP_PEER_ADDR_CHANGE semantics 
(SCTP_ADDR_MADE_PRIM).

The mode of operation does not suit all purposes, but in networks 
environments where a number of equally preferred paths are available,
then by this mode of operation one minimizes the effects of unnecessary 
path bouncing and the thereby associated effects of throughput
degradation due to path changes and slow start operation.

Based on our experiences we would recommend and support that the 
Permanent Failover mode of operation, at least in the simple variant
described above, is promoted as a valid alternative approach. For the 
purpose of activation of this mode of operation a switchback (or failover)
mode operation parameter could be introduced as configurable by the 
introduction of an appropriate new read/write socket option in the 
Socket API.

- Section 5.4: The impact of HB timeouts in association error counter

The draft recommends for excluding HB timeouts from contributing to the 
(association) error counter. We fully support this approach for
all timeouts of HBs that are send to probe the state of destinations 
addresses that are in PF state and we would even propose for the draft
to demand that generally timeouts stemming from HBs, which are not sent 
on the Primary Path, will be excluded from the association error counter.

Thereby the association error counter and thus the association fate 
reflects the forward progress of the data transmission to peer endpoint 
while
at the same time it will be appropriately isolated from timeouts of HBs 
sent on non-data carrying paths.

Allowing timeout of HBs sent on the Primary Path to impact the 
association error counter will serve to validate the aliveness of the 
peer endpoint
when there is no data in transit.

This suggestion follows the thought expressed in 
http://www.ietf.org/mail-archive/web/tsvwg/current/msg11294.html and it 
is thus believed
to fulfil the original intend of RFC4960.

- Section 5.1 Thoughts on the destination address state machine

In RFC4960 address state machine, notification of cease of use of the 
current primary path as transmission path for new data is provided to 
upper layer
via (coupled with) the announcement of the destination as being 
UNREACHABLE. With the introduction of the potentially failed state as a 
semi-hidden
state (not resulting in notified state transition to UL) the information 
on the fail-over to use a new data carrying path is lost.
While there may be merits in suppressing notifications on potentially 
failed addresses, then we believe that it is unfortunate that the 
notification
of failover from usage of the primary path for new data is lost.
This is especially problematic in path bouncing scenarios where the 
primary path is unstable but still works some. E.g., HBs may go through,
but the path breaks (data transmission fails) as soon as it is more 
loaded. In such a situation no notifications may be generated to UL,
even if new data transmission consistently cycles to and from the 
primary path. The solution to such path bouncing scenarios will have to come
from more advanced path failover mechanism, like [CAR002] (and would not 
be solved just by notification), but it would be a great help if appropriate
notifications were provided.