Subject: [tsvwg] Fwd: SCTP Failover ( draft-ietf-tsvwg-sctp-failover-09.txt) - post WGLC

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 11 Mar 2015 23:06:32 -0700

Hi Gorry,

I'm very sorry for the delayed response. We've submitted new version to
address your review.
We've found some editorial mistakes after the submission, but we will fix
them later.
Please check the comments in lines as well as the updated draft.

We appreciate your detailed and accurate comments.

Thanks!
--
Yoshi

On Mon, Feb 2, 2015 at 9:38 AM, Gorry Fairhurst <[email-masked]>
wrote:

> The above document passed WGLC with comments.
>
> My Top-level view is that this is nearly done, and the expected protocol
> seems agreed by the WG during the WGLC (which is great).
>
> However, after a detailed review, I note there are a number of NiTs, but
> more importantly I see ambiguity in the standards language.
> I'm not at all sure after this careful review that this version is ready
> for a detailed IESG review. The later decision to make this PS probably
> avoided some detailed review of the standards language, which I believe
> really needs to be fixed.
>
> My question is: would one of the authors be willing to take this editorial
> role and make an updated draft? - I include comments below to  suggest how
> to finish this process.  I've tried to make suggestions to ease this
> process.
>
> I'd encourage you to make a new revision.
>
> Gorry
>
> ----
>
> I also want to check following the WGLC: I did not see a sentence
> explaining the answer to this:
>
> "- 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."
>

We've added some texts to clarify this point.

> ----
>
> /by introducing of/by introducing/
> /These modes offers for/These modes can allow/
> /more performance optimal operation/improvements in the performance of the
> operation/
> /With procedures specified /With the procedures specified/
>

Done.

>
> Abstract format: (editorial):
> - normally this does not include Reference citations with square brackets,
> usual recommendation is to remove the square brackets. Please update

Done.

> .
>
> Abstract: (editorial):
> - The abstract uses the words /document/ and /memo/ both are acceptable in
> RFCs, but only one term should be used for consistency. The remainder of
> the ID appears to use the term "document".
>

OK. Changed to "document"

>
> Decision on "updates" status.
> - The abstract specifies that it "compliments".  The IESG will require us
> to decide if this updates the SCTP base specification. Is this a change we
> expect all SCTP implementations to support (even if the do not enable), if
> so then I think this is an update to RFC4960. (If this updates, please an
> UPDATES tag to the ID boilerplate.) Community input on determining this is
> appreciated.
>

I thought this doc describes an additional logic to 4960 which doesn't
cause contradiction.
That's why UPDATES tag was not added. However, we're fine to change it
based on the feedback from others.

Introduction: (editorial):
> The text reads:
> "Concurrent Multipath Transfer (CMT) [IYENGAR06] is an extension to SCTP"
> - I'd prefer this to say "proposed extension", since the current document
> is being published as a PS, it should not endorse or otherwise a proposal
> that has not yet reach standardisation.
>

Done.

> (editorial):
> " Also the operation after"
> - could we remove the "also" to avoid starting a paragraph with this word?
>

Done.

> Section 3: (editorial):
> "and start using this address to send data to."
> - may be clearer written as:
> "and starts using this as the destination address for sending data."
>

Done.

> ---
> (editorial):
> "If the primary path becomes active again, SCTP uses the primary
> destination"
> - could this be written as:
> "If the primary path becomes active again, SCTP reverts to using the
> primary destination"
> - or something similar?
>

Done.

> ---
> (editorial):
> "One issue with this failover process "
> - can we ensure "this" is understood. Is it possible to say:
> "One issue with this failover process defined in [RFC4960]"
>

Done.

---
> Section 4.1:
> "SCTP-PF as defined"
> - I don't think this is clear what you refer to. Is this "SCTP-PF defined:
> somewhere else? This is confusing, the definition should be this document.
> If this is design rationale, I'd prefer to see these paras moved to section
> 3 as a conclusion? or to a separate non-normative section.
>

OK. "as defined" has been removed.
It has been preferred to keep the description of  the “PF concept” at this
place in the document.
An alternative choice would be to move section 4.1 and section 5.1. up as
sub-sections within section 3.

---
> Section 4.1:
> The para starting "SCTP-PF defined in this document"
> - This is clear, and I think defines a new variable.
>

We've updated the sentence. Hope it works.

---
> (editorial):
> "and marks the corresponding destination address as PF"
> - but later the ID uses the concept of a PF state. Is it equivalent to say:
> "and marks the corresponding destination address as in the PF state"
>

Done.

---
> Title:
> 4.2.  SCTP-PF Algorithm in Detail:
> - If I understand this, this section contains the specification of the
> mechanism. To avoid ambiguity in what is standardised, could the name for
> this section becomesomething like:
> "Specification of the SCTP-PF Algorithm"
>

Done.

---
> (editorial):
> Section 4.2:
> "error counter of the destination address" - is "of" the correct word,
> should this be "for"?
>

Will change it to "for".

---
> Section 4.2: (editorial):
> "or at times where a HEARTBEAT sent to an idle, active address is not
> acknowledged within an RTO."
> - Unclear - is this
> "or each time a HEARTBEAT chunk is sent when idle and not acknowledged
> within an RTO."
>

Done.

> ---
> Section 4.2, point 2: (editorial):
> - uses the term "destination transport address" in this place only, please
> explain why, or use the term "destination address".
>

Changed to destination address.

> ---
> Section 4.2, point 2: (editorial):
> " MUST mark the destination transport address as PF."
> - but later the ID uses the concept of a PF state. Is it equivalent to say:
> " MUST mark the destination transport address as in the PF state."
> ---
>

Done.

> Section 4.2, point 3: (editorial):
> "The sender SHOULD avoid data transmission to PF destination addresses."
> - can we reword this as:
> "The sender SHOULD avoid data transmission to a destination address are in
> the PF state."
>

Done.

> ----
> (editorial):
> "and some in inactive state"
> - insert "the" before "inactive"
>

Will change.

---
> (editorial):
> "The sender SHOULD choose the destination address in PF state"
> - insert "the" before "PF"
>

Will change.

---
> Format hard to follow:
> Section 4.2, point 3:
> I think this section contains lots of conditions which are a set, would it
> be possible to format as a second-level list to make this clearer?
>

Done. We also did some refactorings to the paragraph and have for clarity
and elaboration split bullet 3 in a new bullet 3 and bullet 4..

> ----
> Section 4.2, point 3: (standards language):
> - So this section makes lots of SHOULD recommendations without really
> saying why they are not MAY or MUST. In particular, there are no notes
> about what happens if the SHOULD is violated. This sort of text tends to
> raise questions in IETF/ISEG review. Can the authors please clarify?
> From reading, I could interpret this as:
>  "The sender SHOULD avoid data transmission to a destination address are
> in the PF state. (To avoid sending to potentially failed destination
> addresses).
>
> "The sender SHOULD choose the destination address in PF state. .... (This
> is to maximise the probability of delivery)"
>

OK. We have updated this section to clarify the standards language part of
the prescriptions. for example:
  new bullet 3: as a SHOULD not to send data to a destination address in PF
state if a destination address in active state exists
  new bullet 4: as a MUST to not send data to an inactive destination
address is a destination address in PF state exists.

The alternative to the SHOULD in the bullet 3. has been clarified as a
possibility that the document description do not intend to prevent.
But, at the same time, the specification of mechanisms that would drive
such a choice is outside of the specified mechanism.

---
> Section 4.2, point 3: nOt sure what this says:
> "A sender may choose to deploy other strategies than the above when
> choosing among
>  multiple PF destinations with equal error count."
> - Trying to unwrap the logic here, I want to be clear whether this is a
> MAY that contradicts the SHOULD in the preceding clauses? - I am not yet
> clear whether this overrides the SHOULD before - this needs clarified.
> ---
>

We think the texts in bullet 4.C clarifies this. The MAY deploy other
strategies is an alternative to the SHOULD.
Again, the deployment of other strategies is not prevented in this
document. But,the specification of mechanisms is outside of the specified
mechanism. So, the SHOULD is prescribed as default behavior.

> Section 4.2, point 3: (editorial):
> "MUST NOT change the state of chosen destination address "
> - what state does this refer to?
>

We updated this sentence.

> ---
>  (standards language):
> "If a HEARTBEAT chunk is not acknowledged, the sender SHOULD increment the
> error counter"
> - I do not understand the SHOULD, are there any conditions under which the
> count needs to not be implemented. Can I challenge whether this needs to be
> "MUST increment"?
>

We have clarified the text by using the MUST for transmission of HBs
towards destination addresses in PF state and using the MUST to ignore the
HB.interval of RFC4960.
For the prescription of how HBs are sent and back-off of the RTO when they
remain unacknowledged, we have chosen to deploy descriptive text with no
keywords as it was also done in RFC4960.
Thereby best possibly retaining the RFC4960 logic and the best current
understanding of the RFC4960 prescriptions for such handling.

---
>  (standards language):
> "and exponentially back off the RTO value."
> - Again, I'd have thought for stability in congestion collapse this was a
> "MUST"?
>

Please see the comment above.

---
> (editorial):
> "packet containing HEARTBEAT chunk immediately"
> - insert "the" before "HEARTBEAT".
>

Done.

---
> (editorial):
> "When data is transmitted to a PF destination,"
> - Is this a "destination marked in the PF state"?
> ---
>

Yes. Changed.

> (editorial):
> "the transmission of HEARTBEAT chunk"
> - insert "a" before "HEARTBEAT".
> ---
>

Done.

> (editorial):
> "as receipt of SACK chunks or a T3-rtx timer expiration"
> - the word "as" is problematic, is this intended to be "when"? - this
> clause needs some additional work to clarify the condition.
>

We've modified the sentence.

> ---
> (editorial):
> "It is RECOMMENDED that HEARTBEAT chunks are send"
> - "send" needs to be "sent".
> - This is equivalent to a SHOULD, so please rephrase with this and include
> a clause in brackets to explain why this is not a MUST.
>

We've changed this to MUST, and forgot to change to sent.. Will fix.

> ---
> (editorial):
> Point 6:
> "SHOULD notify ULP"
> - insert "the" before "ULP" and expand acronym "Upper Layer Protocol
> (ULP)".
>

OK.

---
> (standards language):
> Point 7:
> "When all destinations are in inactive state (association dormant state)
> the sender MUST also choose one destination address to transmit data to."
> - This point does not say the reason why it transmits.
>

 Changed "to transmit data to" to "when data is transmitted" to clarify
this point.

> ---
> (format):
> see note on earlier section - it would be easier to read this as a second
> level indent/bullet list.
> ---
>

Done.

(standards language):
> "thus changing the prescriptions of"
> - "I think the correct term is "updates" - but see the question at the
> start of this review.
>

OK. We'll follow the feedback from people.

> ---
> (standards language):
> "A sender MAY choose to deploy other strategies than the above.  "
> - as above, there are standards requirements above stated as "SHOULD" you
> can not then propose an alternative with a "MAY" that appears to
> contradict. Reformatting as a bullet list could resolve this issue!
> ---
>

We believe reformatting solved the issue.

> (editorial):
> "the Potentially Failed state"
> - other places called the PF state, suggest you us the same term.
>

Done.

---
> "destination address to which the chunk was first transmitted)
>         SHOULD NOT clear the error count of an inactive destination
>         address and SHOULD NOT transition a PF destination address back
>         to Active state, since a sender cannot disambiguate whether the
>         ACK was for the original transmission or the retransmission(s)."
> - I do not understand why these are not required using a MUST - what are
> the safe cases for not following these rules? ... or at least this needs to
> be restructured, for example to explain a sender may have unequivocal
> information to know that a particular destination becomes available, in
> which case it can...; etc ; If this information is not available it MUST ;
> etc.
> - The present MAY clause at the end of the point is problematic and needs
> to resolved by restructuring the clause. (Formatting with indent would
> help).
>

OK. Changed to MUST.

> ---
> (editorial):
> " The implementation of such an alternative approach is left to
> implementations."
> - perhaps should be
> " The design of such an alternative approach is left to implementations."
>

Done.

> ---
> (Standards language):
> Point 10:
> "SCTP stack SHOULD "
> - insert "The" before SCTP"
> - Is this a sender or receiver function? (sender?)

This is sender. but, not sure if we need to specify it.  we think that the
sender role is clear from the context.

- This appears to be a requirements recommendation, so you could use the
> word "RECOMMENDS" rather than SHOULD?
>
>
We've used SHOULD. But, I don't have a strong opinion on this. If people
prefer RECOMMENDS, we are fine.

> ----
> Section 4.3
> - Para 1 and 2 appear to provide informational rationale that could have
> appeared in an earlier informational section - at the moment there is quite
> a lot to read through before you get to the Spec.
>

Well, yes.. but, as this is an optional feature, implementers need to think
about whether implement it or not by checking the rationale.
We have refactored the section so that there is a clear distinction between
the rationale and the logic specification.

> Section 4.3 para 2 ends with a requirements statement that I do not
> understand.
> "
> However as [RFC4960] switchback
>    behavior is suboptimal in certain situations, especially in scenarios
>    where a number of equally good paths are available, it is recommended
>    for SCTP to support also, as alternative behavior, the Permanent
>    Failover switch over modes of operation."
>
> - what is the intended standards compliance statement at the end?
> - Is this an OPTIONAL part of the specification in the document?

- IF it is optional: Is it required to offer this optional to implement the
> spec. (or is it optional to implement? - I think the latter?
> - Can this be re-written clearly... e.g. "A sender that implements the
> OPTIONAL
> Permanent Failover function implements the functions below:..."
>

We've clarify this point at the beginning of the section. It is also
addressed and clarified in the last paragraph of section 4.3.2.

---
> (editorial):
> "
>   A previously failed primary path MAY come in use as data transfer
>        path as per normal path selection when the present data transfer
>        path fails."
> - is this really a "MAY come in use", I think this could be a "can be
> used".
> - insert "a" or "the" before "data"
>

Agreed. Changed to "can be used"

> ---
> (standards language):
> " operation as detailed above and MAY enable it based on network
>    configurations or users' requests."
> - This "MAY" is not a protocol specification. The permission to do it this
> way is give in the previous MAY. Now, can you check this MAY does not
> contradict the previous SHOULD - maybe a small text change can ensure this
> does not conflict?
> ---

OK. We've updated the texts to clarify this point.

> (incomplete security considerations):
> Section 6
> - I'm sure the security area review will ask whether there are really no
> potential new security vulnerabilities. Consider carefully. I'd recommend
> stating here that this is a sender-side only change enabled by
> configuration. Received SCTP chunks used by this protocol are verified as
> specified in RFC 4960, and include protection from off-path security
> attacks. There are no new security considerations introduced in this
> document.
>
>
OK. We have added some texts in the section.

---

From: [email-masked]
Date: Thu, 12 Mar 2015 07:35:57 -0000

Thank you for doing this by the ID-cutoff deadline, and thanks for
progressing this document. I'd like to invite people to read this new
draft, and see if this is ready.

Any editorial NiTs can easily be addressed as soon as the ID archives open.

Gorry

>> in