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

[Michael Tuexen <[e-mail]>]

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.

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.

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.

Best regards
Michael
> 
> Of course, you can ask for alternate text (where you supply the
> actual replacement text, or convey the meaning sufficiently to the
> authors) for anywhere in the document that you find unclear or troublesome.
> 
> James/Gorry/David
> TSVWG chairs
> 
>