Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failover-08 - To conclude 19th November, 2014

[Yoshifumi Nishida <[e-mail]>]

Hi Michael,

On Wed, Nov 19, 2014 at 12:53 PM, Michael Tuexen <
[e-mail]> wrote:

> On 29 Oct 2014, at 15:01, [e-mail] wrote:
>
> > TSVWG,
> >
> > This is the start of a WGLC on "Quick Failover Algorithm in SCTP".
> > https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-08
> >
> > This WGLC will last until Wednesday, 19th November, 2014, this includes
> > the period of the coming IETF meeting.
> >
> > A good note to the list is "I have read this version of the draft,
> > and I approve (or support) its progression to RFC". The chairs
> > request notes to the list showing support to get a sense of the WG.
> Dear TSVSG,
>
> I have read this version of the ID and approve its progression to RFC.
> FreeBSD implements most of the stuff, however exposing the PF_State is
> not implemented yet (so no support for the
> SCTP_EXPOSE_POTENTIALLY_FAILED_STATE
> socket option). Furthermore, FreeBSD doesn't support yet the spt_pathcpthld
> field in struct sctp_paddrthlds, which means FreeBSD doesn't support the
> optional features described in Section 4.3.
>

Thanks for the info.
I just would like to mention that there is no conflict between the draft
and freebsd implementation as these missing features are optional or
informational.


> I have a general remark:
> The document uses the terms
> * Quick failover (it is even in the title of the document)
> * Permanent failover
> * SCTP-PF
> The relation of the above three is not clear for me since they are not
> used consistently.
>

Yes. This makes senses. Thanks for pointing out. We'll think about how to
solve this inconsistency.


> Some editorial comments. Please pick them carefully, since I'm not a native
> speaker and therefore my suggestions might be sub-optimal. But I think the
> language used in the document needs to be improved.


> * Abstract:
>   s/is that it supports multi-homed communication/is the support of
> multi-homing/
>   s/[RFC4960] specified failover operation/failover operation as specified
> in [RFC4960]/
>   s/of SCTP multi-homed operation./of the SCTP failover operation./
>   s/The memo complements RFC 4960/This memo complements [RFC4960]/
>   s/of the Potentially Failed state/of the Potentially Failed path state/
>   s/and associated new/and the associated new/
>   s/during network failure/during a network failure./
>   s/and specifies for SCTP senders to support this
>     more performance optimal failover procedure as an add-on to the
>     [RFC4960] failover operation.//
>   s/The memo in addition complements [RFC4960]/Furthermore this memo
> complements [RFC4960]/
>   s/by introduction of/by introducing of an/
>   s/modes/mode/
>   s/a failover/the recovery of a failed primary path/
>   s/These operation modes offer/This operation mode offers/
>   s/for more performance optimal operation in/performance improvements in/
>   s/From the perspective of this memo the/The/
>   s/considered optional./optional./
>   s/The procedures defined require/The procedures defined in this document
> require/
>
> * Section 1:
>   s/an SCTP association can bind to multiple IP addresses at each
> endpoint/an SCTP endpoint can bind multiple IP addresses./
>   s/network interface redundancy and improved end-to-end fault
> tolerance./network fault tolerance./
>   s/failed retransmissions/failed timer-based retransmissions/
>   s/to SCTP and allows/to SCTP that allows/
>   s/after a failover impacts/after the recovery of a failed path/
>   s/With [RFC4960] procedures/With the procedures specified in [RFC4960]/
>   s/switch back to use the primary path/switch back to the primary path/
>   s/becomes available./becomes available again./
>   s/for SCTP to support the Permanent Failover switchover procedures
> proposed by [CARO02]./the Permanent Failover procedures proposed by
> [CARO02]./
>   s/alternative approach/alternative approaches/
>   s/provided in Appendix./provided in the Appendices./
>
> * Section 3:
>   s/Issues with the SCTP Path Management/Issues with the SCTP Path
> Management as specified in RFC 4960/
>   s/issues in the current SCTP/issues in SCTP as specified in [RFC4960]/
>   s/SCTP can utilize multiple IP addresses for a single SCTP
> association./An SCTP endpoint can support multiple IP addresses./
>   s/initial negotiation/the initial negotiation/
>   s/define this as the primary/use this as the primary/
>   s/SCTP sends/an SCTP endpoint sends/
>   s/heartbeat packets/packets containing a HEARTBEAT chunk/
>   s/of the path./of these destination addresses./
>   s/to secondary destination address, when/ to an non-primary destination
> address, if/
>   s/to be active/to be active and clears the error counter for that
> destination address./
>   s/error count for the/error counter for that/
>   s/protocol parameter 'Path.Max.Retrans'/tunable protocol parameter
> Path.Max.Retrans (PMR)/
>   s/SCTP endpoint/the SCTP endpoint/
>   s/(error counter/(the error counter/
>   s/stop using non-primary one./stops using the non-primary one./
>   s/significant amount/a significant amount/
>   s/starts to use the secondary path./starts to use the non-primary path
> for initial data transmission./
>   s/in the standard/in [RFC4960]/
>   s/before failover takes place/before the failover takes place/
>   s/to the secondary address/to an active non-primary address/
>   s/to the primary/to the primary address/
>   s/to the secondary/to the non-primary/
>   s/and can thus be reached at the receiver./and thus can be received by
> the peer./
>   s/will not be acceptable/is not acceptable/
>   s/path is active again/path becomes active again/
>
> * Section 4:
>   s/updates SCTP path management scheme with the Potentially Failed state
> and associated Quick Failover operation./extends the SCTP path management
> scheme by adding the Potentially Failed state and the associated Quick
> Failover operation./
>
> * Section 4.1:
>   s/minimize performance impact/minimize the performance impact/
>   s/destination/destination address/
>   s/destination/destination address/
>   s/is ideal so that/is better because/
>   s/transitions a destination/can transition a destination address/
>   s/a destination as/a destination address/
>   Define AMR. It is used here the first time.
>   s/address performance impact/address the performance impact/
>   s/This new method/SCTP-PF defined in this document/
>   s/between Active and Failed states/between the Active and Failed state/
>
> * Section 4.2:
>   s/SCTP-PF Algorithm Detail/SCTP-PF Algorithm in Detail/
>   s/SCTP PF operation/The SCTP-PF operation/
>   s/Heartbeats/HEARTBEAT chunks/
>   s/If an heartbeat is unanswered/If a HEARTBEAT chunk is not acknowledged/
>   s/another heartbeat immediately/another packet containing a HEARTBEAT
> chunk immediately/
>   s/of heartbeats may/of HEARTBEAT chunks MAY/
>   s/as SACK or T3-rtx timer/as a T3-rtx timer/
>   s/that heartbeats be send/that HEARTBEAT chunks are send/
>   s/for the destination address/for that destination address/
>   s/receives an heartbeat ACK/receives a HEARTBEAT ACK/
>   s/transmit heartbeats to the/transmit HEARTBEAT chunks to the/
>   s/ACKs/Acknowledgements/
>   s/ACKs/Acknowledgements/
>   s/chunks which has been/chunks that have been/
>   s/ACKs/SACKs/ or s/ACKs/Acknowledgements/
>   s/SCTP stack SHOULD/An SCTP stack should/
>   Wouldn't you also want to signal state changes from PF to Failed and
> vice-versa?
>   s/such SCTP stack MUST/such an SCTP stack must/
>   s/association state transitions/associated state transitions/
>
> * Section 4.3:
>   s/degradation, Permanent Failover/degradation, the Permanent Failover/
>   s/even if the old primary/even when the old primary/
>
> Sorry for the long list of editorial comments, but I wanted to be as
> concrete as possible.
>

Thank you so much! They look very reasonable although we'll need to check
in detail.
We appreciate very detailed comments.

Regards,
--
Yoshi