Re: [babel] Babel-RTT information model and example parameters

Baptiste Jonglez <baptiste.jonglez@imag.fr> Thu, 01 August 2019 14:09 UTC

Return-Path: <baptiste.jonglez@imag.fr>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3283312018A for <babel@ietfa.amsl.com>; Thu, 1 Aug 2019 07:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level:
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 VEVIEUEDpUlm for <babel@ietfa.amsl.com>; Thu, 1 Aug 2019 07:09:11 -0700 (PDT)
Received: from zm-mta-out-1.u-ga.fr (zm-mta-out-1.u-ga.fr [152.77.200.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DA4120170 for <babel@ietf.org>; Thu, 1 Aug 2019 07:09:11 -0700 (PDT)
Received: from zm-mta-out.u-ga.fr (zm-mta-out.u-ga.fr [152.77.200.58]) by zm-mta-out-1.u-ga.fr (Postfix) with ESMTP id B379DA03CA; Thu, 1 Aug 2019 16:09:09 +0200 (CEST)
Received: from smtps.univ-grenoble-alpes.fr (smtps2.u-ga.fr [195.83.24.202]) by zm-mta-out.u-ga.fr (Postfix) with ESMTP id AEF1FE0062; Thu, 1 Aug 2019 16:09:09 +0200 (CEST)
Received: from imag.fr (blaine.imag.fr [129.88.55.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jonglezb@univ-grenoble-alpes.fr) by smtps.univ-grenoble-alpes.fr (Postfix) with ESMTPSA id AA64C607CD; Thu, 1 Aug 2019 16:09:09 +0200 (CEST)
Date: Thu, 01 Aug 2019 16:09:08 +0200
From: Baptiste Jonglez <baptiste.jonglez@imag.fr>
To: "STARK, BARBARA H" <bs7652@att.com>
Cc: 'Juliusz Chroboczek' <jch@irif.fr>, 'Mahesh Jethanandani' <mjethanandani@gmail.com>, "'babel@ietf.org'" <babel@ietf.org>
Message-ID: <20190801140908.i3fa3v4t5r7sbqr6@imag.fr>
References: <20190725151332.ywxjpxpxoritx4ql@imag.fr> <59AF71F0-DFD6-40D4-8A2F-AD7068D28107@att.com> <87wog4ebgi.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E248BD3@GAALPA1MSGUSRBF.ITServices.sbc.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="ld2w4ecpb3b2to24"
Content-Disposition: inline
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E248BD3@GAALPA1MSGUSRBF.ITServices.sbc.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Greylist: Whitelist-UGA SMTP Authentifie (jonglezb@univ-grenoble-alpes.fr) via smtps-465 ACL (99)
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/pGva_BqlYH_9IPJEKfGmWZwhqIQ>
Subject: Re: [babel] Babel-RTT information model and example parameters
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2019 14:09:13 -0000

On Mon, Jul 29, 2019 at 09:11:38PM +0000, STARK, BARBARA H wrote:
> > > The only parameter I think is definitely needed is one to
> > > enable/disable use of RTT in metric calculations.
> > 
> > Unfortunately not.  In a congested and bufferbloated network, tuning of the
> > saturation value (rtt-max) is necessary in order to avoid oscillations.
> > 
> > This mail has the full approval of the Commission for Truth in Advertising.
> > 
> > -- Juliusz
> 
> I see the draft says "In addition, in order to enhance stability (Section 2.3), the mapping should be bounded -- above a certain RTT, all links are equally bad." Is this what you mean by rtt-max? To me, this would indicate it would be ok to define a parameter rtt-max, because it's suggested in the base spec that all implementations have it.

Hmm, it needs more thinking.  Should we require or strongly suggest that
the mapping function has some properties, for instance that it SHOULD be
non-decreasing and bounded?

> Would it be the same rtt-max for all interfaces, or defined per
> interface?

In babeld, we make that configurable per-interface, and it really makes
sense because Babel can be used in heterogeneous networks.

Below is an extract of the babeld man page with all RTT-related
parameters.  They are all per-interface, although babeld also allows to
configure any per-interface setting as a global default.

       rtt-decay <decay>
              This specifies the decay factor for the exponential moving
              average of RTT samples, in units of 1/256.  Must be between
              1 and 256, inclusive.  Higher values discard old samples
              faster.  The default is 42.

       rtt-min <rtt>
              This specifies the minimum RTT, in milliseconds, starting
              from which we increase the cost to a neighbour. The
              additional cost is linear in (rtt - rtt-min).  The default
              is 10 ms.

       rtt-max <rtt>
              This specifies the maximum RTT, in milliseconds, above which
              we don't increase the cost to a neighbour. The default is
              120 ms.

       max-rtt-penalty <cost>
              This specifies the maximum cost added to a neighbour because
              of RTT, i.e. when the RTT is higher or equal than rtt-max.
              The default is 96 if the interface is of type tunnel, and 0
              otherwise.

> Additionally...
> Should this "should" be "SHOULD"? I see no normative language in the draft. Should there be some normative requirements? It seems a bit weird to me to have a specification that doesn't tell you what MUST be done to be compliant with the spec.

Good catch.  We do use normative language in a few places in the draft,
but I agree we should (or SHOULD?) make it more consistent.  I will try to
improve that for the next revision.

Baptiste

-- 
Baptiste Jonglez
PhD student
Univ. Grenoble Alpes <https://www.univ-grenoble-alpes.fr/>
LIG lab <https://www.liglab.fr/>
Drakkar team <http://drakkar.imag.fr/>  |  Polaris team at INRIA <https://team.inria.fr/polaris/>