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/>
- [babel] Babel-RTT information model and example p… Baptiste Jonglez
- Re: [babel] Babel-RTT information model and examp… STARK, BARBARA H
- Re: [babel] Babel-RTT information model and examp… Juliusz Chroboczek
- Re: [babel] Babel-RTT information model and examp… STARK, BARBARA H
- Re: [babel] Babel-RTT information model and examp… Baptiste Jonglez