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

[Michael Tuexen <[e-mail]>]

On 26 Nov 2014, at 11:23, Becke, Martin <[e-mail]> wrote:

> Hi, 
> 
> 2014-11-26 9:27 GMT+01:00 Michael Tuexen <[e-mail]>:
> On 25 Nov 2014, at 20:53, Becke, Martin <[e-mail]> 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.
>> 
>> 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.
>> 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.
> 
> 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. 
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<PMR). 
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
> 
> Best regards
> Martin
>> 
>> - 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 [[e-mail]]&quot; im Auftrag von &quot;[e-mail] [[e-mail]]
>> Gesendet: Mittwoch, 29. Oktober 2014 15:01
>> An: [e-mail]
>> Cc: [e-mail]
>> Betreff: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-failover-08 - To conclude 19th November, 2014
>> 
>> 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.
>> 
>> 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
>> 
>> 
>> 
> 
> 
>