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

From: Baptiste Jonglez <[email-masked]>
Date: Thu, 25 Jul 2019 17:13:32 +0200

Hi Barbara, Mahesh,

The discussion about the information model yesterday and Juliusz' email on
policies got me thinking about the parameters of the babel-rtt extension.

Should the information model specify parameters that are not really part
of the spec?  I'm thinking of the example function for metric computation
and its 3 parameters rtt-min, rtt-max, max-rtt-penalty:

  https://tools.ietf.org/html/draft-ietf-babel-rtt-extension-00#section-2.2.1

This metric function is just an example: an implementation is free to do
something totally different.  So, does it make sense to add the
corresponding parameters (as ro or rw) to the information model?

Sorry if this is a dumb question, I'm quite new to this information model / YANG thing.

Thanks,

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 26 Jul 2019 21:11:19 +0000

Hi Baptiste,
I think you ask an excellent question. We have one case in the current info model of an implementation-specific parameter (the Hello history). After much discussion, we agreed it was useful and easy enough for others to implement — so we kept it. 

But in general — you’re absolutely right that we want to avoid implementation-specific parameters. 

I also think it’s unlikely that people will want to be configuring such parameters (assuming this is all wildly successful and being used by “average” people). 

The only parameter I think is definitely needed is one to enable/disable use of RTT in metric calculations. 

If we ended up with just that, I wouldn’t be upset. But if there is more, that’s fine. I do like the idea of not introducing implementation-specific parameters. 

Thx,
Barbara 

> On Jul 25, 2019, at 11:13 AM, Baptiste Jonglez <[email-masked]> wrote:
> 
> Hi Barbara, Mahesh,
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 26 Jul 2019 23:24:13 +0200

> 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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 29 Jul 2019 21:11:38 +0000

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

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. Would it be the same rtt-max for all interfaces, or defined per interface?

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