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

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 19 Jun 2013 00:23:44 -0700

Hello Salvatore,

I'm sorry for my very slow reply. We've just submitted a new version in
order to avoid expiration status. We've also added some texts for further
discussions.
And thank you so much for the comments. I believe these are very good
suggestions. Please see in line.

On Mon, May 27, 2013 at 6:34 AM, Salvatore Loreto <
[email-masked]> wrote:

> 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.
>

I agree with you to stick to the behavior of RFC4960 as default behavior.
We've been exploring several possibilities for performance improvement and
discussing using 2 MTU might be an idea, although we think we'll need
further discussions. Preethi might have some more comments on this point.

> - 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.
>

Yes. I agree that there will be a situation where Permanent Failover work
effectively. OTOH, supporting this prevents us from keeping RFC4960
behavior as RFC4960 doesn't have this mode.
But, I believe this is a very interesting point and we would like to get
more feedback in order to think about this more.

> - 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<http://www.ietf.org/mail-archive/web/tsvwg/current/msg11294.html>and it is thus believed
> to fulfil the original intend of RFC4960.
>

This is a bit difficult point for me. I don't know much about the original
intention of RFC4960, but if we follow what is written there, i think we
need to increment association error count. (Please correct me if I
misunderstand this point)
So, my personal preference is to set bigger AMR to avoid early termination
so that we can keep the RFC4960 behavior.
However, we don't mind discussing to update the logic described in 4960 for
more sophisticated solution.

>
> - 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.
>

I think it will be OK to send notification as long as it's a new
notification type. But we should not send notifications defined in RFC6458.
I guess having a new notification type won't cause problems, but I would
like to get more feedback on this.

Thanks!
--
Yoshifumi