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

From: Baptiste Jonglez <[email-masked]>
Date: Thu, 1 Aug 2019 16:09:08 +0200

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/>