Re: [Teas] Mirja Kühlewind's Discuss on draft-ietf-teas-rsvp-te-scaling-rec-06: (with DISCUSS and COMMENT)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Thanks!

> Am 14.02.2018 um 16:05 schrieb Vishnu Pavan Beeram <[e-mail]>:
> 
> Thanks for clearing the discuss!
> 
> I'll push in an update to the draft with the changes I proposed yesterday.
> 
> Regards,
> -Pavan
> 
> On Wed, Feb 14, 2018 at 6:13 AM, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
> Hi Paven,
> 
> thanks for the explanation and sorry for the finally quite long delay. I had just not enough of RSVP knowledge to figure out how you are detecting a node failure. Thanks for the explanation below. I also didn’t realize that the previous default refresh interval was recommended as 30 second, which seems high.
> 
> Knowing that there is a mechanism to detect node failure and stop sending, I will clear my discuss now. Again thanks for the explanation and patient!
> 
> I believe actually your newly proposed text is more clear and I would still recommend to use that. I believe what confused me most was the use of the term „retransmission“ in the current section 2.3. It’s not fully wrong but if your motivation is to maintain a shorter refresh interval (as previously used) in situation where it is unclear if state was refreshed with the last message, I would phrase it like this, as in our new proposed text.
> 
> Mirja
> 
> 
> 
> > Am 14.02.2018 um 03:21 schrieb Vishnu Pavan Beeram <[e-mail]>:
> >
> > Mirja, Hi!
> >
> > Glad that the proposed text helped in understanding this better.
> >
> > All that the text is trying to say is the following --
> > In traditional RSVP (2961 capable) implementations, the interval used for refreshing state associated with unacked Path/Resv messages is the same as the regular refresh interval (R). But since we are now advocating the use of a large value for R, it makes sense to maintain a distinction between the refresh interval for unacked Path/Resv messages and the regular refresh interval.
> >
> > Your concerns (if I understood them right) aren't really against the procedures discussed in <rsvp-te-scaling-rec>. They are against how traditional RSVP (2961 capable) works. Let me see if I can address those. Please see inline (prefixed VPB)..
> >
> > Regards,
> > -Pavan
> >
> > On Tue, Feb 13, 2018 at 3:49 PM, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
> > Hi Pavan,
> >
> > thanks a lot! This text change did help me to at least understand better what you are proposing. I'm still concerned that in a situation where all messages probably have been lost in the rapid retry phase, which is an indication of congestion, you still keep sending messages with a rather low but still higher rate than in the regular refresh interval of 20min.
> > Can you explain why this is considered to be beneficial?
> >
> > [VPB] This is because RSVP can't determine how long congestion would last on the neighboring node and it is important for signaling state (Path/Resv) to be kept in sync between neighbors. The congestion may clear up a couple of seconds after the rapid-retry phase (for a particular message) is complete or it may clear up 24 hours later. As long as the neighbor is deemed UP (is able to maintain "hello" session), signaling state associated with that neighbor will keep getting refreshed (this is just how RSVP works). If the neighbor gets congested enough to bring down the corresponding hello session, then appropriate "signaling adjacency failure" actions (this may include state tear down) would come into play.
> >
> >
> > I believe using some kind of extended exponential back-off would still be more appropriate. Also e.g. if you actually send the message every 30s for e.g. 20 minutes and don’t get an ACK, you might still want to give up and log an error (termination condition), no? I hope that makes now sense to you?
> >
> > [VPB]  Let us assume that the implementation gives up after a few retries and stops refreshing state associated with unacked Path/Resv messages. What should happen to the "state" now? You can't retain the state, because there is no prescribed way of determining when to start refreshing the state again (Note -- neighbor never went down; hellos are intact; interface to the neighbor is still UP). If you can't retain the state, then you must tear it down. But that is too extreme an action to take (especially if the data-plane is intact). I hope that explains why implementations keep refreshing state.
> >
> >
> >
> > Mirja
> >
> >
> >
> > > Am 13.02.2018 um 19:13 schrieb Vishnu Pavan Beeram <[e-mail]>:
> > >
> > > 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) <[e-mail]> 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 <[e-mail]>:
> > > >
> > > > 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) <[e-mail]> 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 <[e-mail]>:
> > > > >
> > > > > 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 <[e-mail]> 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) <[e-mail] <mailto:[e-mail]>> 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
> > > > >     <[e-mail] <mailto:[e-mail]>>:
> > > > >
> > > > >      >
> > > > >      > 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)
> > > > >     <[e-mail] <mailto:[e-mail]>> 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
> > > > >     <[e-mail] <mailto:[e-mail]>>:
> > > > >      > >
> > > > >      > > 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
> > > > >     <[e-mail] <mailto:[e-mail]>> 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
> > > > >      > > [e-mail] <mailto:[e-mail]>
> > > > >      > > https://www.ietf.org/mailman/listinfo/teas
> > > > >     <https://www.ietf.org/mailman/listinfo/teas>
> > > > >      > >
> > > > >      >
> > > > >      >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Teas mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/teas
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > Teas mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/teas
> > >
> >
> >
> 
>