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

From: Michael Tuexen <[email-masked]>
Date: Wed, 19 Nov 2014 21:53:34 +0100

On 29 Oct 2014, at 15:01, [email-masked] 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
> 
>

---

From: "Becke, Martin" <[email-masked]>
Date: Tue, 25 Nov 2014 19:53:22 +0000

Hi all, 

I read the draft and I still think the algorithm described is functional and useful. I like the idea to introduce a potentially failed state (PF) to optimize the send process. 

I have only some questions/comments (No editorial comments, perhaps a native speaker can check the text, too):

- Perhaps the authors can give me a hint why it should be RECOMMENDED  to set the PFMR value to 0 when Quick Failover is used.  I would expect a value > 0 when it is used and 0 when it is not(!) used.   

- I think the term “multiple destinations” irritates.  Perhaps you can use “destination addresses” or “addresses” instead”.  FMPOV the use of the term “destination” in this draft is inaccurate.  In general the terms path, destination, destination address are very mixed for my feeling. Perhaps this can be rechecked.   

- “Heartbeats SHOULD be sent to PF destination(s) once per RTO. This means the sender MUST ignore HB.interval for PF destinations.”
 
This sounds strange to me. Why is SHOULD used here and what are the alternatives, when I MUST ignore HB.interval for PF destinations. I guess a rephrase of this two lines can help. 

- A link is missing in Section 5.1: [RFC6458] defines the constants SCTP_ADDR_AVAILABLE,….

Best 
________________________________________
Von: tsvwg [[email-masked]]&quot; im Auftrag von &quot;[email-masked] [[email-masked]]
Gesendet: Mittwoch, 29. Oktober 2014 15:01
An: [email-masked]
Cc: [email-masked]
Betreff: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failover-08 - To conclude 19th November, 2014

TSVWG,

James/Gorry/David
TSVWG chairs

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 26 Nov 2014 09:27:54 +0100

> - Perhaps the authors can give me a hint why it should be RECOMMENDED  to set the PFMR value to 0 when Quick Failover is used.  I would expect a value > 0 when it is used and 0 when it is not(!) us…
Because it is not a flag controlling the usage of Quick Failover, but a threshold. See second item
in the enumeration in Section 4.2.

Best regards
Michael

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 26 Nov 2014 00:42:05 -0800

Hi Michael,

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

> The relation of the above three is not clear for me since they are not

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

>   s/an SCTP association can bind to multiple IP addresses at each
> endpoint/an SCTP endpoint can bind multiple IP addresses./
>   s/for SCTP to support the Permanent Failover switchover procedures
> proposed by [CARO02]./the Permanent Failover procedures proposed by
> [CARO02]./
>   s/SCTP can utilize multiple IP addresses for a single SCTP
> association./An SCTP endpoint can support multiple IP addresses./
>   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:

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

Regards,
--
Yoshi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 26 Nov 2014 00:42:31 -0800

Hi Martin,

Thanks for the comments.

On Tue, Nov 25, 2014 at 11:53 AM, Becke, Martin <[email-masked]>
wrote:

> Hi all,
>
> I read the draft and I still think the algorithm described is functional
> and useful. I like the idea to introduce a potentially failed state (PF) to
> optimize the send process.
>
> - Perhaps the authors can give me a hint why it should be RECOMMENDED  to
> set the PFMR value to 0 when Quick Failover is used.  I would expect a
> value > 0 when it is used and 0 when it is not(!) used.
>

Setting PFMR to 0 means one single timeout triggers Quick Failover.
According to some studies, this will be the most efficient setting as you
can quickly utilize another available path. Setting PFMR to PFMR > 0 &&
PFMR < PMR means you'll need some consecutive timeouts before Quick
Failover is triggered.
As described, when PFMR >= PMR, Quick Failover will be turned off.

> - I think the term “multiple destinations” irritates.  Perhaps you can use
> “destination addresses” or “addresses” instead”.  FMPOV the use of the term
> “destination” in this draft is inaccurate.  In general the terms path,
> destination, destination address are very mixed for my feeling. Perhaps
> this can be rechecked.
>

OK. We'll check this.

>
> - “Heartbeats SHOULD be sent to PF destination(s) once per RTO. This means
> the sender MUST ignore HB.interval for PF destinations.”
>
> This sounds strange to me. Why is SHOULD used here and what are the
> alternatives, when I MUST ignore HB.interval for PF destinations. I guess a
> rephrase of this two lines can help.
>

I see your point. We'll think about this. I think we should change SHOULD
to MUST for now.

> - A link is missing in Section 5.1: [RFC6458] defines the constants

Thanks for pointing out! We'll fix this.

Regards,
--
Yoshi

> Von: tsvwg [[email-masked]]&quot; im Auftrag von &
> quot;[email-masked] [[email-masked]]

---

From: "Becke, Martin" <[email-masked]>
Date: Wed, 26 Nov 2014 10:23:19 +0000

Hi, 

2014-11-26 9:27 GMT+01:00 Michael Tuexen <[email-masked]>:

> in the enumeration in Section 4.2.

Yes, exact. I only wonder why the threshold is not used as control flag, too.
FMPOV there is no difference for the algorithm if the threshold PFMR has another interpretation. 
Instead defining the trigger with the event error counter > threshold it might be a alternative to define the trigger with threshold = error counter. 
Thus the PFMR can be used as control flag, too. This has the benefit, that the Quick Failover is always deactivated by 0, even if the PMR will be reßconfigured over the time (increased so that PFMR<PMR). 

Best regards
Martin

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 26 Nov 2014 16:17:18 +0100

> Instead defining the trigger with the event error counter > threshold it might be a alternative to define the trigger with threshold = error counter. 
This is for consistency with the usage of thresholds in other cases. We always use
the the counter exceeds the threshold, then do...
> Thus the PFMR can be used as control flag, too. This has the benefit, that the Quick Failover is always deactivated by 0, even if the PMR will be reßconfigured over the time (increased so that PFMR…
This is what we use in FreeBSD to disable quick failover per default:
net.inet.sctp.path_rtx_max: 5
net.inet.sctp.path_pf_threshold: 65535
Whatever value you configure PMR to, quick failover is off.

Best regards
Michael