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

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Mon, 16 October 2017 10:25 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B131344B0 for <teas@ietfa.amsl.com>; Mon, 16 Oct 2017 03:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAy-HOoRiMVu for <teas@ietfa.amsl.com>; Mon, 16 Oct 2017 03:25:09 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80313133347 for <teas@ietf.org>; Mon, 16 Oct 2017 03:25:08 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=gvAw9w0Ysok0e5aoWPMMbTY6K8eoDWzyldcmyscXnEepQL6yOvS0Fe5SF1Yes3KbP/KCI/mWeEZS+ffpLuXAIafsIrujJivOtAzFGa7QREZ1D1JQbn6nYSoNsXl+58uJYToisP/I9qPL47qwTcMWUj22ysAOsnXYvibWPPbEbFs=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 6126 invoked from network); 16 Oct 2017 12:25:06 +0200
Received: from p5dec287e.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.40.126) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Oct 2017 12:25:06 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <CA+YzgTt77KmC1g2+C==c0F2BxWS0PEiuP-R0SNvWiv=_OO7s9Q@mail.gmail.com>
Date: Mon, 16 Oct 2017 12:25:04 +0200
Cc: draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, TEAS WG Chairs <teas-chairs@ietf.org>, The IESG <iesg@ietf.org>, "teas@ietf.org" <teas@ietf.org>, Lou Berger <lberger@labn.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FFA062AD-A257-4AA8-8DE6-C7B03330DF81@kuehlewind.net>
References: <150644890311.20830.6212136664552694640.idtracker@ietfa.amsl.com> <CA+YzgTtqT9Ojs8Ed8fwW3FCLGVaJMTgCxsonH1Gxe-H7Q85orA@mail.gmail.com> <BBCF6104-8351-4C90-BD38-6A515DCAB9E5@kuehlewind.net> <CA+YzgTt77KmC1g2+C==c0F2BxWS0PEiuP-R0SNvWiv=_OO7s9Q@mail.gmail.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20171016102506.6117.87655@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/fP3hrrWJt2itcgd_vEUDRtNLPF0>
Subject: Re: [Teas] Mirja Kühlewind's Discuss on draft-ietf-teas-rsvp-te-scaling-rec-06: (with DISCUSS and COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Oct 2017 10:25:12 -0000

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.“

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.

Mirja




> Am 05.10.2017 um 22:27 schrieb Vishnu Pavan Beeram <vishnupavan@gmail.com>:
> 
> 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) <ietf@kuehlewind.net> 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 <vishnupavan@gmail.com>:
> >
> > 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) 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 <ietf@kuehlewind.net> 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
> > 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/
> >
> >
> >
> > ----------------------------------------------------------------------
> > 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
> > Teas@ietf.org
> > https://www.ietf.org/mailman/listinfo/teas
> >
> 
>