Subject: Re: [tsvwg] Shepherd Write-Up for draft-ietf-tsvwg-sctp-failover

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 3 Dec 2015 14:49:07 -0600

Hi, Gorry,

On Mon, Sep 21, 2015 at 6:01 AM, Gorry Fairhurst <[email-masked]>
wrote:

>
> As a WG Chair, I am pleased to note the support of the TSV WG in
> progressing this document towards standards publication as a PS, and
> enclose here the writeup to our AD requesting publication.
>
> Gorry Fairhurst

I've had an opportunity to do AD Evaluation for this draft. It's good work,
but I do have a fair number of editorial comments I'd like you to consider
(my theory is that if we can clean up minor items before IETF Last Call,
the Last Call conversations will be shorter and more pleasant).

Please let me know if I've misunderstood things below.

And thanks for the good shepherd report, by the way.

Spencer, as AD

In this text

   While SCTP-PF can accelerate failover process and improve
   performance, the risks that an SCTP endpoint enters in dormant state
                    I'd say "enters the dormant state" ^^
   where all destination addresses are inactive can be increased.

In this text

   The operation after the recovery of a failed path equally well
   impacts the performance of the protocol.

I'm not clear on "equally well impacts the performance of the protocol". Is
this "also impacts the performance of the protocol"?

This text

   The issue cannot simply be mitigated by lowering of the PMR threshold
   because this may result in spurious failure detection and unnecessary
   prevention of the usage of a preferred primary path as well as it,
   due to the coupled tuning of the Path.Max.Retrans (PMR) and the
   Association.Max.Retrans (AMR) parameter values in [RFC4960], may
   result in compromisation of the fault tolerance of SCTP.

is really confusing. Splitting it into at least two sentences would
probably help, but I can't follow it closely enough to make a specific
suggestion.

In this text

   The new failure detection algorithm assumes that loss detected by a
   timeout implies either severe congestion or network connectivity
   failure and it assumes that by default a destination address is
   classified as PF already at the occurrence of one first timeout.

I'm not understanding "already at the occurrence of one first timeout". Is
this saying "at the occurrence of the first timeout"?

This text

        Setting PFMR larger to or equal to
        Path.Max.Retrans (PMR) does not result in definition of a PF
        threshold for the destination address.  I.e., the destination
        address will not be classified as PF prior to reaching inactive
        state.

was difficult for me to parse. Is it saying

        If PFMR is set to be greater than or equal to
        Path.Max.Retrans (PMR), the resulting PF threshold will be so high
        that the destination address will reach the
        inactive state before it can be classified as PF.

? I should also ask if it makes sense for an SCTP-PF implementation to
create a PF threshhold high enough that failures go through the long
detection process and only failover when the destination address reaches
the inactive state - if I'm reading this correctly. Would this happen
intentionally?

I wonder whether

   3.   The PFMR threshold defines the point the destination address no
        longer is considered a good candidate for data transmission and
        a SCTP-PF sender SHOULD NOT send data to destination addresses
        in PF state when alternative destination addresses in active
        state are available.

could be shortened to something like

   3.   A SCTP-PF sender SHOULD NOT send data to destination addresses
        in PF state when alternative destination addresses in active
        state are available.

In this text

        When data is being transmitted to a destination
        address in the PF state, the transmission of a HEARTBEAT chunk
        MAY be omitted in case receipt of a SACK of or a T3-rtx timer
                       ^^^^^^^^^^^^^^^
        expiration on the outstanding data can provide equivalent
        information, such as a case where the data chunk has transmitted
        to a single destination.

I'm reading "in case receipt of" as "in the case of receipt of" (I think a
couple of words are missing), but I'm also wondering if just saying "when"
would be clearer.

In this text

        This document makes no reference to what
        such unequivocally information could consist of, neither how
        such unequivocally information could be obtained.

I think "neither" should be "nor".

In this text

   12.  The SCTP stack SHOULD provide the ULP with the means to expose
        the PF state of its destinations as well as the means to notify
        of state transitions from active to PF, and vice-versa.

I think "to notify of" is correct, but it reads awkwardly to me. Is it "to
notify the ULP of"?

In this text

   For an [RFC4960]
   SCTP implementation the continuation of data transmission during
   dormant state makes the fault tolerance of SCTP be more robust
   towards situations where some, or all, alternative paths of an SCTP
   association approach, or reach, inactive state prior to that the
   primary path used for data transmission observes trouble.

"prior to that" reads roughly to me. Is this saying "before"?

In this text

       The exact limit to apply is not
       specified in this document but it is considered reasonable to
       require for such to be an order of magnitude higher than the PMR
       value.

"require for such" reads roughly to me. Is this saying "require the limit"?

In this text

       A sender MAY choose to deploy other strategies that the
       strategy defined by here.

"that the strategy defined by here" reads roughly to me. Is this saying
"than the strategy defined here"?

I'm noticing that the document uses "switch over" a few times, but mostly
"switchover". Is the difference intentional?

In this text

   The manner of switch over operation that is most optimal in a given
   scenario depends on the relative quality of a set primary path versus
   the quality of alternative paths available as well as it depends on
                                                         ^^^^^^^^^^
   the extent to which it is desired for the mode of operation to
   enforce traffic distribution over a number of network paths.

I think you can drop the second "it depends".

In this text

   On the other hand, usage of the Primary Path Switchover mechanism,
   does change the treat analysis.  This is because attackers can force
                   ^^^^^
   a permanent change of the data transfer path by blocking the primary
   path until the switchover of the primary path is triggered by the
   Primary Path Switchover algorithm.

is that "threat" analysis? But more to the point, do you have to be on-path
to force a permanent change by blocking? If so, and you're on-path, can't
you cause just about as much trouble for a [RFC4960] implementation? If so,
you might want to talk about "on-path attackers". I'd expect that would
shorten the conversation with SECDIR reviewers.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 4 Dec 2015 10:47:06 -0800

Hi Spencer,

Thanks for the detailed comments. We started working on a revised
version. We'll get back to you in a couple of days.

Regards,
--
Yoshi

On Thu, Dec 3, 2015 at 12:49 PM, Spencer Dawkins at IETF
<[email-masked]> wrote:
>> progressing this document towards standards publication as a PS, and enclose
>> here the writeup to our AD requesting publication.
>>
>> Gorry Fairhurst
>
>
> (my theory is that if we can clean up minor items before IETF Last Call, the
> Last Call conversations will be shorter and more pleasant).
>
> is really confusing. Splitting it into at least two sentences would probably
> help, but I can't follow it closely enough to make a specific suggestion.
>
> In this text
>
> detection process and only failover when the destination address reaches the
> inactive state - if I'm reading this correctly. Would this happen
> intentionally?
>
> I wonder whether
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 9 Dec 2015 09:00:33 -0800

Hi Spencer,

Thanks for the detailed comments. We have updated the draft based on your
suggestions and submitted.
Please check the newer version to see if this is fine for you.
In the meantime, I put comments in lines.

>> progressing this document towards standards publication as a PS, and
enclose
> (my theory is that if we can clean up minor items before IETF Last Call,
the
>    where all destination addresses are inactive can be increased.

OK.

> this "also impacts the performance of the protocol"?

Yes, we've updated the text.

> is really confusing. Splitting it into at least two sentences would
probably
> help, but I can't follow it closely enough to make a specific suggestion.

Sorry for the confusion.
The intention of the sentence should be like something this.
I hope this will make a sense to you.

  The issue cannot simply be mitigated by lowering of the PMR threshold
  because this may result in spurious failure detection and unnecessary
  prevention of the usage of a preferred primary path.

  Also,due to the coupled tuning of the Path.Max.Retrans (PMR) and the
  Association.Max.Retrans (AMR) parameter values in RFC4960, lowering of
  the PMR threshold may result in lowering of the AMR threshold, which may
  result in compromisation of the fault tolerance of SCTP.

> this saying "at the occurrence of the first timeout"?

Yes, I hope the following sentence will be clearer.

   The new failure detection algorithm assumes that loss detected by a
   timeout implies either severe congestion or network connectivity
   failure. It recommends that by default a destination address is
   classified as PF  at the occurrence of the first timeout.

>         inactive state before it can be classified as PF.

Yes. We've updated the text as you suggested.

> detection process and only failover when the destination address reaches
the
> inactive state - if I'm reading this correctly. Would this happen

Yes, It can happen intentionally. This is because it's the current behavior
of SCTP.
If someone wants to disable PF feature for some reason, they can do it by
tuning PFMR.

>         in PF state when alternative destination addresses in active

OK.

>         MAY be omitted in case receipt of a SACK of or a T3-rtx timer

OK. We've updated this paragraph like the followings.

  When data is being transmitted to a destination address in the PF state,
  the transmission of a HEARTBEAT chunk
  MAY be omitted in case where the receipt of a SACK of the data or a
T3-rtx timer
  expiration on the data can provide equivalent information, such as in the
  case where the data chunk has been transmitted to a single destination
address only.
  Likewise, the timeout of a HEARTBEAT chunk MAY be ignored when data is
  outstanding towards the destination address

> I think "neither" should be "nor".

OK.

> I think "to notify of" is correct, but it reads awkwardly to me. Is it "to

We've updated this paragraph like the followings to be clearer.

      12.  The SCTP stack SHOULD expose the PF state of its destination
           addresses to the ULP as well as provide the means
           to notify ULP  of state transitions of its destination addresses
           from active to PF, and vice-versa.

We have further clarified the following text of the paragraph as:

     .  However it is recommended that an
        SCTP stack implementing SCTP-PF also allows for that the ULP is
        kept ignorant of the PF state of its destinations and the
        associated state transitions, thus allowing for retain of the
        simpler state transition model of RFC4960 in the ULP.  For this
        reason it is recommended that an SCTP stack implementing SCTP-PF
        also provides the ULP with the means to suppress exposure of the
        PF state and the associated state transitions.

> "prior to that" reads roughly to me. Is this saying "before"?

Yes. We've updated.

> "require for such" reads roughly to me. Is this saying "require the
limit"?

Yes. Updated.

> "than the strategy defined here"?

Yes. Updated.

> "switchover". Is the difference intentional?

OK. we updated the draft to use only "switchover".

>    the quality of alternative paths available as well as it depends on

OK. We've updated.

> shorten the conversation with SECDIR reviewers.

Yes, we fixed the typo.
Also, yes, you have to be on-path for this. We updated texts to mention it.
The difference from RFC4960 with this regard is you just need to be on-path
until switchover happens.
Say you have two paths and your primary is relatively roust than
the secondary one.
If you can have a chance to be on-path on the primary for short amount of
time (but, enough to cause switchover),
you'll have a bigger chance to compromise the association.