Subject: [tsvwg] Standards language comments on draft-ietf-tsvwg-sctp-failover

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 12 Mar 2014 15:35:11 +0000

This document was presneted at the IETF meeting in Londin and I am 
performing a review to understand the request to update the document 
status to PS. Please do not take this as crictism of the propsed method, 
it is not.

This document needs a much clearer abstract that sets the scope, rather 
than motivates an update.

I also need to see a document with stronger standards recommendations to 
proceed with a more detailed review.

Gorry
(tsvwg co-chair)

----

Abstract.

I think the abstract needs to be more clearly worded:

"However, if the SCTP standard is followed, there can be
    a significant delay during the migration.  During this period, SCTP
    might not be able to transmit much data to the peer.  This issue
    drastically impairs the usability of SCTP in some situations.  This
    memo describes the issue of the SCTP failover mechanism and specifies
    an alternative failover procedure for SCTP that improves its
    performance during and after failover.  The procedures require only
    minimal modifications to the current specification."

- This reads like a proposal, instead you should be clear about what 
this document as an update offers, rather than trying to justify the change.

I think this document updates RFC 4960. - If it does, then is the 
mechanism that you describe here an OPTIONAL extension to the spec, or a 
REQUIRED update to the spec. I think it is the former. I also understnad 
that this is a sender-side only change, and that it does not impact the 
SCTP receiver, is this correct. These details need to be clear in the 
abstract and also the introduction to this ID.

---

Section 2 defines terminology, but then section 3,4 seem purely 
informative. I'd personally prefer to see the RFC 2119 declaration at 
the start of section 5, and clearly state at the start of section 5 that 
it defines the normative update.

---

Section 3.

It may be worth adding a starting sentence, saying that "this section 
provides an informative review of the need for this update". You could 
also add "This assumes familiarity with the terminology in [RFC4960]."

---

Section 4

- I do not really understand what your intent is with this sentence:
" The following approaches are conceivable for the solutions of this
    issue."
- Are these previously proposed approaches?
- Do these contradict the RFCs published.
- Does the WG (or authors) have any opinion about the suitability of 
deploying these 2 methods in the general Internet?

Section 4.1

"ignores several recommendations in [RFC4960]."
(1) OK, I could read RFC 4960, but then I would prefer just to ask:
What do you mean by "ignores", are these RFC 2119 recommendations, or 
just discussed items.

(2) Maybe the text you are looking for is that it
"would contradict recommendations in [RFC4960]."?
- I assume each is called out in turn later in the document?

- So does this conclude that these approaches are not recommended?

Section 4.2

"However, if we can choose smaller value"
              ^^^^^^^^^^^^^^
- could we change this to
"However, if the sender uses a smaller value"

"can contribute to keep RTO value small."
- is this better witten as:
"can contribute to a small RTO value."
- I'm assuming this is not deisrable due to increased probability of RTO 
expiry, but you don't say? - please explain what this causes.

"although it needs to ignore several recommendations described in the
    Section 15 of [RFC4960]."
- as above, ignoring? what? - is this actually updating?

- So does this conclude that these approaches are not recommended?

---

Section 5.1 (first part)

The first part appears to define a different approach. Is this intended 
as the proposed update, or is an alternative like other methods in 
section 4. I'm unclear.

Section 5.1 (second part)

"tweaking the PMR value" is this "tuning the PMR value"?

"between Active and Failed states."
         ^
- insert /the/

"detection procedure is modified"
                         ^^^^^^^^
- Probably clearer to say as: "This document updates SCTP's failure 
detection procedure to include the PF state."

"address will be incremented"
          ^^^^^^^
- address MUST be incremented.

"   3.  The sender SHOULD avoid data transmission to PF destinations."
- You say SHOULD - can you give examples of when not to do this?

"       When all destinations are in either PF or Inactive state, the
        sender MAY either move the destination from PF to Active state
        (and transmit data to the active destination) or the sender MAY
        transmit data to a PF destination. "
- You say MAY ... or MAY ..., I don't understand this construct
- I suspect that you mean MUST do either this ... or this ....

"It is recommended" - is that a SHOULD, i.e. RECOMMENDED - or can you 
rephrase this as an example.

"In case of a tie"
    ^
- insert /the/

"with same error"
      ^
- insert /the/

"the sender MAY choose the last active destination."
- I am not sure I understand the MAY here, the need I think is to 
specify an outcome for a tie, and this is one example. I don't see that 
MAY is helpful, either give it as ane example, or say SHOULD and provide 
a counter example when it is not true.

"4. Only heartbeats MUST be sent to PF destination(s) once per RTO."
- I don't understand the "MUST" - Is it that "heartbeats MUST be sent to 
PF destination(s) once per RTO" or is it something else?

"If an heartbeat is unanswered, the sender
        increments the error counter and exponentially backs off the RTO
        value.  "
- Isn't this part of the spec: /increments/MUST increment/

"If error counter is"
    ^
- insert /the/

"5. When the sender receives an heartbeat ACK from a PF destination,
        the sender clears the destination's error counter and transitions
        the PF destination back to Active state."
- There is no requirement, could we change "clears" to "MUST clear"

"  The sender should
        perform slow-start as specified in Section 7.2.1 of [RFC4960]
        when it sends data on this destination."
- should? - why only should and not MUST?

"6.  Additional (PMR - PFMR) consecutive timeouts on a PF destination
        confirm the path failure, upon which the destination transitions
        to the Inactive state."
/transitions/MUST transition/

"This proposal recommends "
- Is this an example, or a real recommendation?
- It is anyway not a proposal when published...
Suggest /This update RECOMMENDS/

"In case of a tie (multiple Inactive
        destinations with same error count), the sender MAY choose the
        last active destination."
- As above,  I am not sure I understand the MAY here, the need I think 
is to specify an outcome for a tie, and this is one example. I don't see 
that MAY is helpful, either give it as ane example, or say SHOULD and 
provide a counter example when it is not true.

"9. SCTP shall provide the means to expose the PF state of its"
/SCTP shall/an SCTP sender MUST/ ?

        destinations as well as SCTP SHOULD notify the ULP of the state
/as well as SCTP SHOULD/In addition, an SCTP sender SHOULD
        transitions from Active to PF and from PF to Active state.

"SCTP can provide the means to suppress exposure of PF state and"
/SCTP can/An SCTP sender MAY/

"PF state to ULP"
             ^
- insert /the/

/if quick/
    ^
- insert /the/

"there is no serious problem with SCTP in terms of path"
- This isn't clear to me, I think you need to explain what was tested 
and why this does not pose a problem - are the tests for performance? 
conenctivity? and in what conditions?
- Are you claiming therefore that there is no risk when used in the 
general Internet? or there is no evidence of problems in the general 
Internet? - I'm not sure.

If I understand, Section 5.2 appears to describe why someting is not an 
issue - this is good to have, but it seems a little odd in the middle of 
the spec.

Section 5.3

* I have not understood if this is a REQUIRED part of the update, an 
optional part or what. Is this section also normative?

"Post failover then, by [RFC4960] behavior, an SCTP sender migrates
- Found this hard to follow.
- Could it mean "When the original path (primary) is restored after a 
failover,  [RFC4960] requires the SCTP sender to migrate..."

"in scenarios where this
    path's characteristics are better."
- is this the original (primary) or the failover path, sorry for being 
dense.

"it as new primary.'
       ^
- insert /the/

Failover allows SCTP sender to continue
                ^
- insert /an/

"Details, as originally outlined in [CARO02], are:"
- if this is part of this ID, then you need to ammed the wording to not 
be ambiguous about the spec. For example.
"[CARO02] described a description of a method. This update requires the 
following:"

Please use MUST SHOULD MAY RECOMMENDS carefully in this list of 4 points.

1. suggest you chnage / the SCTP implementation autonomously selects/ to 
/the SCTP sender MUST selects/

2. /shall/MUST/

3. /recommended/RECOMMENDED/

4. /It must be/It MUST be/

"We recommend that SCTP-PF should stick to the standard RFC4960
    behavior as default,"

suggest:
"The default behaviour for an SCTP-PF implementation
is to use the standard method sepcified in RFC4960."

---

Section 7. You should state the security considerations of RFC 4960 also 
apply to this document. This document does not raise new security concerns.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 13 Mar 2014 01:21:29 -0700

Hi Gorry,

Thanks for the very detailed review.
I mostly agree with your comments and suggestions. I've inserted some
comments to address your questions.
We will update new version.

On Wed, Mar 12, 2014 at 8:35 AM, Gorry Fairhurst <[email-masked]>wrote:

> performing a review to understand the request to update the document status
> to PS. Please do not take this as crictism of the propsed method, it is not.
>
> - This reads like a proposal, instead you should be clear about what this
> document as an update offers, rather than trying to justify the change.
>

Yes. PF is an optional extension to the spec and requires sender-side only
change. We will clarify this point.

> informative. I'd personally prefer to see the RFC 2119 declaration at the
> start of section 5, and clearly state at the start of section 5 that it
> defines the normative update.
>
> ---
>
> Section 3.
>
> provides an informative review of the need for this update". You could also
> add "This assumes familiarity with the terminology in [RFC4960]."
>
> OK. We will add some texts for this.

> deploying these 2 methods in the general Internet?

These are the approach that have been investigated in research papers.
They need to use some un-recommended values for some parameters. (not sure
this means contradict, though)
This might trigger unwanted side-effects in some cases as we explained in
the section.

> What do you mean by "ignores", are these RFC 2119 recommendations, or just
> discussed items.
>

These are RECOMMENDED values.

> - So does this conclude that these approaches are not recommended?

Hmm. I'm not very sure if we need to conclude this.
Our intention was showing options which don't use PF as possible
alternatives (and potential problems for them)
As PF is optional extension, I thought people have freedom not to use it.
If they are careful enough and accept the possibility for adverse side
effects, I think it'll be fine.

Section 4.2
> "However, if we can choose smaller value"

OK.

> expiry, but you don't say? - please explain what this causes.

Yes. We mentioned that " However, this approach requires to have enough
knowledge about the network characteristics between end points. Otherwise,
it can introduce adverse side-effects such as spurious timeouts."
I thought this approach might be fine in some confined environments.

> - So does this conclude that these approaches are not recommended?

This is almost similar to 4.1. They will need to ignore RECOMMENDED and
SHOULD value there.
Again, I'm not very sure if we need to conclude. But, I think we can say
something like
"this approach is not recommended unless you have enough knowledge..." if
it sounds reasonable.

> ---
>
> Section 5.1 (first part)
>
> The first part appears to define a different approach. Is this intended as
> the proposed update, or is an alternative like other methods in section 4.
> I'm unclear.
>

OK. This is our proposed method and we will clarify it.

> - address MUST be incremented.

OK.

> - You say SHOULD - can you give examples of when not to do this?

The following sentence describes the example.

> - I suspect that you mean MUST do either this ... or this ....

It implicitly means that you can choose not to send data..

> - I am not sure I understand the MAY here, the need I think is to specify
> an outcome for a tie, and this is one example. I don't see that MAY is
> helpful, either give it as ane example, or say SHOULD and provide a counter
> example when it is not true.
>
> This is just a weak recommendation. Because we're not very sure this is
really helpful anyway.
I think we can change it to "may" to indicate there's no strong intention
behind this.

> PF destination(s) once per RTO" or is it something else?

You might want to send HB once per HB.interval as specified in 4960. So, we
need to override 4960 here.

> - Isn't this part of the spec: /increments/MUST increment/

Hmm. you're right. In RFC4960, RFC2119 word is not used for error count for
some reasons. So, we tried to follow the convention.
But, I think we can use MUST here.

> - There is no requirement, could we change "clears" to "MUST clear"

Same as above. I think we can use MUST.

> - should? - why only should and not MUST?

Since this is related to CC, I prefer just to say "follow 4960". We will
revise this part.

> /transitions/MUST transition/

OK.

> Suggest /This update RECOMMENDS/

OK.

> - As above,  I am not sure I understand the MAY here, the need I think is
> to specify an outcome for a tie, and this is one example. I don't see that
> MAY is helpful, either give it as ane example, or say SHOULD and provide a
> counter example when it is not true.
>

This is not mandatory. I think MUST is not appropriate. MAY?

> /SCTP can/An SCTP sender MAY/

OK.

> - This isn't clear to me, I think you need to explain what was tested and
> why this does not pose a problem - are the tests for performance?

OK. I think we will clarify this in new version.

> issue - this is good to have, but it seems a little odd in the middle of

I agree.

> optional part or what. Is this section also normative?

This is optional. In earlier version of the draft, this feature was not
recommended.
We will think about where and how we should put section 5.2 and 5.3

> - is this the original (primary) or the failover path, sorry for being

 It's the failover path. We'll revise these parts to clarify the intention.

> - if this is part of this ID, then you need to ammed the wording to not be
> ambiguous about the spec. For example.

OK.

> OK

> apply to this document. This document does not raise new security concerns.

Yes. Thanks for pointing this out.

Thanks,
--
Yoshifumi

---

From: [email-masked]
Date: Thu, 13 Mar 2014 11:21:50 -0000

Great thanks for getting back quickly, I think this tightening of language
will be more appropriate for a PS - my responses in-line.

Gorry

>> status
>> this
OK
>> the
>> also
>> just
OK, so they suggest changes to the recommended values... I think I
understand.
> effects, I think it'll be fine.
Indeed, people can choose or not to use a PS - and can meet the standard,
even if they change recommended  - providing they can justify why the new
values are "safe".

But then asa reviewer, and especially if this is published as a "PS", I
think it would be wise to provide one IETF-recommended way of doing
things. If you are suggesting that there are multiple alternative ways of
doing this and this is a PS, I'd expect a more detailed analysis of when
each case is recommended, and to say explicitly what each alternative
alternative methods changes.

In summary, I think you need to either take this as a background review of
other approaches (I think you suggest this?), *OR* to provide much clearer
detail and guidance on the other methods.

> "this approach is not recommended unless you have enough knowledge..." if
Saying this is not recommended for the general Internet is OK. I'm not
sure I like use of "knowledge", maybe you could remove this.

If you think it's needed, perhaps you could consider ",but may be
applicable in specific deployment scenarios"... but then can you give
examples why this is better than the PS method in specific cases, to
explain why this document is simply not silent on this?

>> as
I think we need new text, I still don't undestand.

>> specify
Please avoid "may" in this context, if you think it is "one alternative"
then just use those words. The intent of a lowercase "may" is not clear.
> But, I think we can use MUST here.
Please suggest text in the next rev (perhaps the difference could be that
this update relies on this to function, whereas it's only a counter in RFC
4960? ) BTW, insert also a MUST after the "and" if you want this to also
be normative.
> Since this is related to CC, I prefer just to say "follow 4960". We will
But require (MUST) that you follow?

>> is
That would be OK for me, propose a RFC 2119 keyword.
>> and
OK
> We will think about where and how we should put section 5.2 and 5.3
You could for example then prefix the section with "Implementation and use
of the mechanism described in this section is OPTIONAL and is not needed
to support the mechanisms described in section xxx".

OK

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 14 Mar 2014 00:50:55 -0700

Hi Gorry,

Thanks for the comments. I put my comments inline.

> detail and guidance on the other methods.

OK. I am personally not very sure if another analysis will be needed as
detailed analysis has already been made.
But, I think we can provide some texts to provide some guidance.
We will think about this more to clarify our intention.

> explain why this document is simply not silent on this?

OK. I don't think "knowledge" part is needed because we don't want to
recommend this approach as it won't be good to be used in general Internet.

> I think we need new text, I still don't undestand.

OK. We will make it more explicit.

OK

> But require (MUST) that you follow?

Yes. We'll put MUST here.

OK.

---

From: [email-masked]
Date: Fri, 14 Mar 2014 08:27:43 -0000

See in-line.

Gorry

>> >> to PS. Please do not take this as crictism of the propsed method, it
>> is
>> >> not.
>> >>
>> But then as a reviewer, and especially if this is published as a "PS", I
>> other approaches (I think you suggest this?), *OR* to provide much
>> clearer detail and guidance on the other methods.
>>
>
I'd be happy to see this just noted in the informative background, and
focus on the one approach.  I look forward to hearing what you propose in
the next rev.

> recommend this approach as it won't be good to be used in general
Fine.

>> >> the proposed update, or is an alternative like other methods in
>> section
>> >> 4.
>> >> I'm unclear.
>> >>
>> >
>> > You might want to send HB once per HB.interval as specified in 4960.
>> So,
>> > we
>> > Hmm. you're right. In RFC4960, RFC2119 word is not used for error
>> count
>> > for