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

[Lou Berger <[e-mail]>]

Umm, perhaps I'm misunderstanding your objection, but the message 
retransmission strategy is inherent in RSVP's (rfc2205) Soft State approach.

Lou


On January 12, 2018 7:19:40 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
>>
>>
>
>