Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-failover-12.txt

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Tue, 1 Sep 2015 09:04:04 +0200

Hi All,

We have updated the draft after comments received during WGLC.
The below reflects the changes done.

The authors consider this document as ready for submission towards the IESG.

Changes from ver 11-12:
------------------------------

#1:  Comment received from Gorry Fairhurst on usage of SCTP-PF acronym:

Gorry:  My specific suggestion was to define PF early in the introduction,
e.g.

   To address this problem, this
   document specifies a quick failover algorithm (SCTP-PF) based on the
   introduction of a new Potentially Failed (PF) path state in SCTP path
                                             ^^^

Change done:  “(PF)” added as suggested in the first paragraph of section 1.

#2:  Change of Permanent Failover Name:

Comments received by Gorry Fairhurst:
Is it worth renaming "permanent failover" as "permanent path failover" - to
avoid any ambiguity with respect to pf=permanent failover that could happen
to someone looking through this spec.?

At tsvwg sessions during IETF 93 it was discussed that it was best to remove
this redundancy in the terms.

Change done: The “Permanent Failover” name has been changed to “Primary Path
Switchover”. The feature indeed performs an automatic switchover of the
Primary Path and this term is thus
considered to very well represent the feature.

#3:  SHOULD or should on certain notifications to ULP.

Comments received by Maxim Proshin:

In bullet 8 there it is said “(i) SHOULD notify” and later in the same
bullet time there is in (ii) a reference to section 8.3 of RFC4960. However
section 8.3 of RFC4960 speaks about the delivery of notifications as
optional.
This is inconsistent.

Discussion:

RFC4960 is inconsistent in that it in section 8.2 specify the event
generation as a SHOULD and in section 8.3 as optional.
The reference in (ii) of bullet 8 of SCTP-PF to RFC4960 section 8.3 however
does not apply to the statement in (i) of bullet 8 of SCTP-PF.

Further after speaking to RFC4960 authors and RF4960bis author group it has
been clarified that the intention is to have this inconsistency be removed
in RFC4960bis, so
that event generations be required consistently as a SHOULD when indeed a
SHOULD is believed appropriate for the event as it is in this particular
case.

The should in bullet 12 came in version 11 as it was thought that api
considerations should not be covered by keywords following RFC4960
semantics.  But RFC4960 is inconsistent and does in some places use keywords
and in other places not. With the recognition that api considerations for
event generation may be required with keywords when desired/required, it has
been decided to revert the should of bullet 12 to a SHOULD.

The issue has been discussed with Michael Tuexen and Randy Stewart which
have noted their agreement.

Change Done:

No change is done in bullet 8.

In bullet 12 a change of  should  SHOULD has been done thus reverting to
the previous versions.

#4: Change of specification from MUST to SHOULD with MAY for the following
features:

Comment from Maxim Proshin:

Ericsson SCTP SW does not follow the MUST of bullet 7 in _all_ situations.
Ericsson SCTP SW aims to have the path error counters reflect the fate
of data transmissions as far as possible when such are outstanding and not
have the success of HBs reset the error counters if data does not get
through.
This gives added robustness in situations where peculiar bugs or overload
conditions allow for HBs to be answered while data never makes it through.
It is proposed to change the first MUST in bullet 7 to a SHOULD.

Discussion:

The issue has been discussed with Michael Tuexen and Randy Stewart which
have noted their agreement in that the flexibility provided by the SHOULD
(opposed to the MUST) is
desirable and that this issue may deserve some mentioning as well in
RFC4960bis both from a path counter as well as from an association counter
reset perspective. It is noted that Errata 3788
addressed parts of the same overall issue.

The issue have been thought to be addressed in some version of the SCTP-PF
draft but seemed to have “been forgotten” in the meanwhile.

Changes done:

In bullet 7 and in bullet 10.

Old text, ver-11, bullet 7:

   7.   When the sender receives a HEARTBEAT ACK from a HEARTBEAT sent
        to a destination address in PF state, the sender MUST clear the
        error counter of the destination address and transition the
        destination address back to active state.  When the sender
        resumes data transmission on the destination address, it MUST do
        this following the prescriptions of Section 7.2 of [RFC4960].

New text, ver-12, bullet 7:

   7.   When the sender receives a HEARTBEAT ACK from a HEARTBEAT sent
        to a destination address in PF state, the sender SHOULD clear the
        error counter of the destination address and transition the
        destination address back to active state.  When the sender
        resumes data transmission on the destination address, it MUST do
        this following the prescriptions of Section 7.2 of [RFC4960].
        In the situation where an HB ACK arrives while there is data
outstanding
        towards the destination address to which the HEARTBEAT was sent,
        then an implementation MAY choose to not have the HB ACK reset the
error counter
        but have the error counter reset await the fate of the yet
outstanding data transmission.

Old text, ver-11, bullet 10:

   10.  Acknowledgments for chunks that has been transmitted to one ..

New text, ver-12, bullet 10:

   10.  Acknowledgments for data chunks that has been transmitted to one ..

#5: Conflict with using both MUST NOT and MAY on the same issue:

Comment from Maxim Proshin:

Usage of MUST NOT and MAYs in bullet 9. is inconsistent.

Discussion:

MUST NOTs shall be changed to SHOULD NOTs.
This change of keyword in effect is an editorial (typo) correction:

Change done:

Old text, ver-11:
   9.   Acknowledgments for chunks that have been transmitted to
        multiple destinations (i.e., a chunk which has been
        retransmitted to a different destination address than the
        destination address to which the chunk was first transmitted)
        MUST NOT clear the error count for an inactive destination
        address and MUST NOT transition a destination address in PF
        state back to active state, since a sender cannot disambiguate
        whether the ACK was for the original transmission or the
        retransmission(s).  A SCTP sender MAY apply a different approach
        for the error count handling based on unequivocally information
        on which destination (including multiple destination addresses)
        the chunk reached.  This document makes no reference to what
        such unequivocally information could consist of, neither how
        such unequivocally information could be obtained.  The design of
        such an alternative approach is left to implementations.

New text, ver-12:

   9.   Acknowledgments for chunks that have been transmitted to
        multiple destinations (i.e., a chunk which has been
        retransmitted to a different destination address than the
        destination address to which the chunk was first transmitted)
        SHOULD NOT clear the error count for an inactive destination
        address and SHOULD NOT transition a destination address in PF
        state back to active state, since a sender cannot disambiguate
        whether the ACK was for the original transmission or the
        retransmission(s).  A SCTP sender MAY apply a different approach
        for the error count handling based on unequivocally information
        on which destination (including multiple destination addresses)
        the chunk reached.  This document makes no reference to what
        such unequivocally information could consist of, neither how
        such unequivocally information could be obtained.  The design of
        such an alternative approach is left to implementations.

#6: Various editorial comments:

The document has been updated in accordance with the following editorial
comments kindly provided by Maxim Proshin or self-discovered.

ALP (Application Layer Protocol)  ULP (Upper Layer Protocol) following
RFC4960 semantics.

multi homing => multi-homing (two occurrences in text)

PF destination -> destination address in PF state (multiple places)

Potentially-Failed => Potentially Failed (section header of section 3)

truely => truly

in [RFC4960] path management scheme => in the [RFC4960] path
management(section 3.1)

When choosing among multiple destination address in active state
        the following considerations are given:
=>
When choosing among multiple destination addresses in active state
        the following considerations are given:

the sender should let the choice among the multiple PF destination with
equal error count
=> the sender should let the choice among the multiple PF destinations with
equal error count

to Active state => to active state

Acknowledgments => acknowledgments

For this
        reason is it recommended that an SCTP stack implementing SCTP-PF
        also should provide the ULP with the means to suppress exposure
        of PF state and the associated state transitions.
=>
For this
        reason it is recommended that an SCTP stack implementing SCTP-PF
        also should provide the ULP with the means to suppress exposure
        of PF state and the associated state transitions.

A [RFC4960]
       SCTP implementation of Permanent Failover MUST support the
       setting of PSMR = PMR An [RFC4960] SCTP implementation of
       Permanent Failover MAY support larger settings of PSMR > PMR.

A [RFC4960]
       SCTP implementation of Permanent Failover MUST support the
       setting of PSMR = PMR. An [RFC4960] SCTP implementation of
       Permanent Failover MAY support larger settings of PSMR > PMR.

BR, Karen/Yoshifumi

>-----Original Message-----
>From: tsvwg [mailto:[email-masked]] On Behalf Of internet-
>[email-masked]
>Sent: Tuesday, September 01, 2015 8:58 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-failover-12.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Transport Area Working Group Working
> Group
>of the IETF.
>
>        Title           : SCTP-PF: Quick Failover Algorithm in SCTP
>        Authors         : Yoshifumi Nishida
>                          Preethi Natarajan
>                          Armando Caro
>                          Paul D. Amer
>                          Karen E. E. Nielsen
>	Filename        : draft-ietf-tsvwg-sctp-failover-12.txt
>	Pages           : 22
>	Date            : 2015-08-31
>
>Abstract:
>   SCTP supports multi-homing.  However, when the failover operation
>   specified in RFC4960 is followed, there can be significant delay and
>   performance degradation in the data transfer path failover.  To
>   overcome this problem this document specifies a quick failover
>   algorithm (SCTP-PF) based on the introduction of a Potentially Failed
>   (PF) state in SCTP Path Management.
>
>   The document also specifies a dormant state operation of SCTP.  This
>   dormant state operation is required to be followed by an SCTP-PF
>   implementation, but it may equally well be applied by a standard
>   RFC4960 SCTP implementation.
>
>   Additionally, the document introduces an alternative switchback
>   operation mode called Primary Path Switchover that will be beneficial
>   in certain situations.  This mode of operation applies to both a
>   standard RFC4960 SCTP implementation as well as to a SCTP-PF
>   implementation.
>
>   The procedures defined in the document require only minimal
>   modifications to the RFC4960 specification.  The procedures are
>   sender-side only and do not impact the SCTP receiver.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-12
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-failover-12
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Tue, 1 Sep 2015 09:57:29 +0200

HI,
It seems that some problems occurred with one of the tools and there are
some strange typos in the document uploaded.
Please await a version -13.
BR, Karen

>From: Karen Elisabeth Egede Nielsen [mailto:[email-masked]]
>Sent: Tuesday, September 01, 2015 9:04 AM
>To: [email-masked]; [email-masked]; Black, David
>Cc: Yoshifumi Nishida
>Subject: RE: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-failover-12.txt
>
>Hi All,
>