Subject: Re: [Teas] Mirja Kühlewind's Discuss on draft-ietf-teas-rsvp-te-scaling-rec-06: (with DISCUSS and COMMENT)
From: Vishnu Pavan Beeram <[email-masked]>
To: "Mirja Kuehlewind (IETF)" <[email-masked]>
Cc: Lou Berger <[email-masked]>, TEAS WG Chairs <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
Date: Tue, 13 Feb 2018 13:13:20 -0500
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>

Mirja, Hi!

Thanks for the response!
It doesn't seem like we can make progress here if I keep recycling the same
set of responses. I seem to have exhausted the "this is normal RSVP soft-
state signaling behavior" line of argument :)

I don't want to spend too much time arguing about a subtlety that
(probably) only folks who have implemented RSVP-TE understand. So, let me
try a different take on this.

How about the following changes to the document?

**
- Remove Section 2.3 (this takes out the contentious text)

- Make the following change in Section 3
  OLD:

   o  MUST make the default value of the configurable refresh interval
      be a large value (10s of minutes).  A default value of 20 minutes
      is RECOMMENDED by this document.

  NEW:

   o  MUST make the default value of the configurable refresh interval
      (R) be a large value (10s of minutes).  A default value of 20
      minutes is RECOMMENDED by this document.

   o  MUST use a separate refresh interval for refreshing state associated
      with unacknowledged Path/Resv messages (uR).  A default value of
      30 seconds is RECOMMENDED by this document.

- Make the following change in Appendix A.
  OLD:

      (d) Periodic Retransmission Interval for unacknowledged Path/Resv
      messages (uR) - 30 seconds (Section 2.3).
      If the Retry-Limit (Rl) is 7, then it takes 31.5 seconds for the 7
      rapid retransmit steps to max out (The last delay from message 6
      to message 7 is 16 seconds).  After the 7 rapid retransmit steps
      are maxed out, the router starts periodic retransmission on a
      slower timer.  This document recommends the use of the traditional
      default refresh interval value of 30 seconds for this periodic
      retransmission interval.

  NEW:

      (d) Refresh interval for refreshing state associated with
      unacknowledged Path/Resv messages (uR)- 30 seconds (Section 3).
      The recommended refresh interval (R) value of 20 minutes (for an
      implementation supporting RI-RSVP) can not be used for refreshing
      state associated with unacknowledged Path/Resv messages. This
      document recommends the use of the traditional default refresh
      interval value of 30 seconds for uR.

***

Let me know if the above changes address your concerns.

Regards,
-Pavan

On Tue, Feb 13, 2018 at 9:22 AM, Mirja Kuehlewind (IETF) <
[email-masked]> wrote:

> Hi Pavan,
>
> I believe you that there may be implementation that transmit indefinitely,
> however, that is not how I read RFC2961:
>
> " The staged retransmission will continue
>    until either an appropriate MESSAGE_ID_ACK object is received, or the
>    rapid retry limit, Rl, has been reached.“
>
> or
>
> „The sending node will retransmit the message until a message
>    acknowledgment is received or the message has been transmitted a
>    maximum number of times.“
>
> For me these sentences say that one should not retransmit anymore after
> the max number is reached. If this is implemented differently, that is a
> not safe behavior and need to be clarified. There must be a termination
> condition. It is not safe for the stability of the Internet to retransmit
> packets indefinitely. Packet loss can have may reason but continuous packet
> loss is a clear sign of congestion that one can not be ignored.
>
> Mirja
>
>
>
> > Am 12.01.2018 um 14:15 schrieb Vishnu Pavan Beeram <
> [email-masked]>:
> >
> > Mirja, Hi!
> >
> > I thought the following response (sent on Oct 5th 2017) addressed this
> concern.
> >
> > ** Copying text from an earlier email **
> > There is nothing new about Path and Resv messages getting transmitted
> indefinitely (this is normal soft-state signaling behavior). All that is
> being discussed in this section is how these transmissions get paced after
> the rapid retry limit is reached. The slower timer transmission will go on
> until either an ack is received (at which point the regular "refresh
> interval" comes into play) or the corresponding LSP instance state is torn
> down.
> > **
> >
> > Please let me know if this still doesn't address the concern. We can set
> up a call and walk through the base RSVP specs.
> >
> > Regards,
> > -Pavan
> >
> > On Fri, Jan 12, 2018 at 7:12 AM, Mirja Kuehlewind (IETF) <
> [email-masked]> wrote:
> > Hi Vishnu, hi all,
> >
> > sorry but I lost a little bit track of this and looking at this now the
> clarification provided below do not seem to address my concern. My concern
> is that for messages (that a MESSAGE_ID object with the ACK_Desired flag
> set), these messages would retransmit forever (even though only every 30s)
> and there is not stop criteria to finally give up (and report an error).
> >
> > Mirja
> >
> >
> > > Am 22.12.2017 um 08:44 schrieb Vishnu Pavan Beeram <
> [email-masked]>:
> > >
> > > Mirja, Hi!
> > >
> > > Please see if the responses above address your concerns. Please let us
> know if there are any issues with progressing this document.
> > >
> > > Regards,
> > > -Pavan
> > >
> > > On Mon, Nov 13, 2017 at 4:21 AM, Lou Berger <[email-masked]> wrote:
> > > Hi,
> > > Please see below.
> > >
> > > On 11/13/2017 5:57 AM, Vishnu Pavan Beeram wrote:
> > > Mirja, Hi!
> > >
> > > Apologize for the delayed reply.
> > > Please see inline for responses (prefixed VPB).
> > >
> > > Regards,
> > > -Pavan
> > >
> > > On Mon, Oct 16, 2017 at 6:25 AM, Mirja Kuehlewind (IETF) <
> [email-masked] <mailto:[email-masked]>> wrote:
> > >
> > >     Hi Vishnu,
> > >
> > >     I don’t think what you proposed is a clarification at all. RF2961
> > >     clearly reads to me that you should not retry any more after the
> > >     Rapid retry limit has been reached:
> > >
> > >
> > >     "Rl is the maximum number of times a message will be
> > >                 transmitted without being acknowledged.“
> > >
> > >
> > > Please not that this section applies to "a message containing a
> MESSAGE_ID object with the ACK_Desired flag set" and
> > >
> > > The ACK_Desired flag will typically be set only in trigger messages.
> > >
> > > This means that these procedure does not apply to normal RSVP refresh
> processing and that  normal RFC2205 defined Refresh Processing or Summary
> Refresh processing continues.
> > >
> > >
> > > [VPB] Yes. As per RFC2961, the retry limit (Rl) is the maximum number
> of times a message will be transmitted without being acknowledged. But this
> just governs the number of times you retransmit the message during the
> "rapid retransmission phase".
> > >
> > > RFC2961 is silent about what happens after the "rapid retransmission
> phase" is complete and this is the clarification that is being provided
> here in the <scaling-rec> draft.
> > >
> > > The draft is silent in general about anything that is *not* modified
> by the draft.  I think having the informative statement is appropriate.
> > >
> > > Note that the associated RSVP Path/Resv state doesn't get cleaned up
> after the "rapid retransmission" phase is complete. So at each subsequent
> refresh-interval, the unacked Path/Resv message will be sent out again
> (note that if there is no change in the state, the same MESSAGE_ID would
> get used). This behavior has always existed in RSVP-TE implementations --
> so it is incorrect to deduce from the "RFC 2961" text above that the
> retransmission of the unacked Path/Resv will never happen after the "Rl" is
> reached.
> > >
> > >
> > > Agreed.
> > > Lou
> > >
> > >
> > >     Also RFC2961 suggests an initial Rf of 500ms with 7 retries and and
> > >     delta of 2, that means you will see the following retries:
> > >
> > >     1. after 500ms
> > >     2. after 1000ms
> > >     3. after 2000ms
> > >     4. after 4000ms
> > >     5. after 8000ms
> > >     6. after 16000ms
> > >     7. after 32000ms
> > >
> > >     and then give up. While you suggests to send all 300ms section
> > >     afterwards forever. That is not acceptable and can lead to
> congestion.
> > >
> > >
> > > No, that is not what is being suggested.
> > > RFC2961 suggests an Rf of 500ms with 3 retries and a delta of 2. So
> the rapid retransmissions would be:
> > > 1. after 500ms
> > > 2. after 1000ms
> > > 3. after 2000ms.
> > >
> > > With the proposal in the <scaling-rec> draft, you would try 7 times
> and then stop the "rapid retransmission phase". So, what that means is that
> the rapid retransmission phase lasts 31.5 seconds (first retry is after
> 500ms and the seventh retry is after 32000ms). After this "rapid
> retransmission phase" is complete, you keep sending the message out every
> 30000ms (30seconds is not 300ms) until an acknowledgement is received.
> > >
> > > Hope this helps.
> > >
> > >
> > >
> > >     Mirja
> > >
> > >
> > >
> > >
> > >      > Am 05.10.2017 um 22:27 schrieb Vishnu Pavan Beeram
> > >     <[email-masked] <mailto:[email-masked]>>:
> > >
> > >      >
> > >      > Mirja, Hi!
> > >      >
> > >      > This was discussed in my response to Elwyn. I apologize for not
> > >     responding directly.
> > >      >
> > >      > RFC2961 doesn't discuss what to do with the retransmissions
> after
> > >     the retry limit is reached. It doesn't discuss how retransmissions
> > >     need to be paced after the rapid retries are stopped. Section 2.3
> > >     (ver 7) of the current draft clarifies this and proposes the use of
> > >     a "not so rapid (30secs)" retransmission interval.
> > >      >
> > >      > There were a couple of questions from this section that you
> > >     wanted to get discussed:
> > >      > ----
> > >      > (1) Why is there no termination criteria specified?
> > >      > There is nothing new about Path and Resv messages getting
> > >     transmitted indefinitely (this is normal soft-state signaling
> > >     behavior). All that is being discussed in this section is how these
> > >     transmissions get paced after the rapid retry limit is reached. The
> > >     slower timer transmission will go on until either an ack is
> received
> > >     (at which point the regular "refresh interval" comes into play) or
> > >     the corresponding LSP instance state is torn down.
> > >      >
> > >      > ----
> > >      > (2) Why couldn't the regular refresh interval be used for these
> > >     un-acked retransmissions?
> > >      > The primary goal of the retransmission is to eke out an
> > >     acknowledgement from the neighbor as quickly as you can. You can
> use
> > >     the same value as the the regular refresh interval provided it is
> > >     small enough (like in the case of the conventional refresh interval
> > >     of 30 secs) . However, we are recommending the use of a "large
> > >     refresh interval" (20 mins) in the RI-RSVP technique -- we can't
> > >     wait that long for retrying the transmission of an unacked message.
> > >      >
> > >      > Consider a rudimentary state machine with the following states
> > >     (assuming the defaults suggested in the Appendix of the draft):
> > >      > - first retransmit (exponential back off)
> > >      > - second retransmit (exponential back off)
> > >      > ...
> > >      > - seventh retransmit (exponential back off)
> > >      > - 30s retransmission
> > >      > - 20m refresh (regular refresh timer)
> > >      >
> > >      > At any point when the Ack is received, you transition to the 20m
> > >     refresh state.
> > >      >
> > >      > ---
> > >      >
> > >      > Do these two responses adequately answer your questions?
> > >      >
> > >      > Regards,
> > >      > -Pavan
> > >      >
> > >      > On Thu, Oct 5, 2017 at 7:57 AM, Mirja Kuehlewind (IETF)
> > >     <[email-masked] <mailto:[email-masked]>> wrote:
> > >      > Hi Pavan,
> > >      >
> > >      > I don’t see any changes in the new version that addresses may
> > >     actual discuss on section 2.1.3 (now section 2.3). Can you please
> > >     clarify?
> > >      >
> > >      > Thanks,
> > >      > Mirja
> > >      >
> > >      >
> > >      > > Am 28.09.2017 um 05:45 schrieb Vishnu Pavan Beeram
> > >     <[email-masked] <mailto:[email-masked]>>:
> > >      > >
> > >      > > Mirja, Hi!
> > >      > >
> > >      > > Thanks for the review. We just posted a new revision (-07) to
> > >     address the Gen-Art review comments. Please go through the new
> diffs
> > >     (https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-
> scaling-rec-07
> > >     <https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-
> scaling-rec-07>)
> > >     and let us know if additional changes are required.
> > >      > >
> > >      > > Also, please go through the responses provided to the other
> > >     review comments and let us know if there are still any unanswered
> > >     questions.
> > >      > >
> > >      > > Regards,
> > >      > > -Pavan
> > >      > >
> > >      > >
> > >      > >
> > >      > > On Tue, Sep 26, 2017 at 2:01 PM, Mirja Kühlewind
> > >     <[email-masked] <mailto:[email-masked]>> wrote:
> > >      > > Mirja Kühlewind has entered the following ballot position for
> > >      > > draft-ietf-teas-rsvp-te-scaling-rec-06: Discuss
> > >      > >
> > >      > > When responding, please keep the subject line intact and reply
> > >     to all
> > >      > > email addresses included in the To and CC lines. (Feel free to
> > >     cut this
> > >      > > introductory paragraph, however.)
> > >      > >
> > >      > >
> > >      > > Please refer to
> > >     https://www.ietf.org/iesg/statement/discuss-criteria.html
> > >     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> > >      > > for more information about IESG DISCUSS and COMMENT positions.
> > >      > >
> > >      > >
> > >      > > The document, along with other ballot positions, can be found
> here:
> > >      > >
> > >     https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-
> scaling-rec/ <https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-
> scaling-rec/>
> > >
> > >      > >
> > >      > >
> > >      > >
> > >      > >
> > >     ------------------------------------------------------------
> ----------
> > >      > > DISCUSS:
> > >      > >
> > >     ------------------------------------------------------------
> ----------
> > >      > >
> > >      > > I'm uncertain what section 2.1.3. actually recommends. My
> > >     understanding is that
> > >      > > it is recommend to still send retransmit some message even if
> > >     the Rl was
> > >      > > reached and to that every 30s basically forever. First of all
> I
> > >     think this
> > >      > > still needs a termination criteria when to stop to try to
> > >     retransmit finally.
> > >      > > And the I don't understand why this is needed, instead of e.g.
> > >     just using a
> > >      > > larger Rl value? Can you please clarify!
> > >      > >
> > >      > >
> > >      > >
> > >     ------------------------------------------------------------
> ----------
> > >      > > COMMENT:
> > >      > >
> > >     ------------------------------------------------------------
> ----------
> > >      > >
> > >      > > I fully agree with the gan-art review (Thanks Elwyn!) and
> > >     Alvaro, that this
> > >      > > reads from time to time like a BCP but is actually a extension
> > >     specification. I
> > >      > > would strongly recommend to apply the changes proposed by the
> > >     gen-art review,
> > >      > > and there is also a very detailed list of nits/edits that
> > >     should probably be
> > >      > > applied. Please have a look at that!
> > >      > >
> > >      > >
> > >      > > _______________________________________________
> > >      > > Teas mailing list
> > >      > > [email-masked] <mailto:[email-masked]>
> > >      > > https://www.ietf.org/mailman/listinfo/teas
> > >     <https://www.ietf.org/mailman/listinfo/teas>
> > >      > >
> > >      >
> > >      >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Teas mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/teas
> > >
> > >
> >
> >
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>