Subject: [babel] Information model: fast-convergence

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 27 Jul 2020 17:59:48 +0200

Dear all,

Barbara proposed a switch called (if memory serves) "fast-convergence"
that is essentially a macro that changes the values of a number of
parameters to values that make convergence faster at the cost of higher
overhead.  More exactly, the followng values are influenced by it:

  - Hello Interval;
  - IHU Interval;
  - Update Interval;
  - IHU Hold Time;
  - Route Expiry Time.

It is my opinion that this switch should not be added.

First of all, the values given in Appendix B of 6126bis are just examples;
the protocol is robust enough to function with a wide range of parameters,
and I expect implementations to use different sets of parameters in
different kinds of networks.  (The only reason they appear as "recommended
defaults" is because some IESG members appear to be unable or unwilling to
accept the notion of a robust algorithm.  Please ignore this recommendation,
and experiment with the values most suitable in your particular network.
You will probably find out that only the Hello Interval matters, and that
the algorithm compensates for all of the other values.)

Second, the switch was inspired by an alternative set of parameters in
Appendix B of 6126bis.  This was introduced during a lengthy and confused
discussion with Mirja Kuehlewind, and it was removed when it turned out
that this was not what Mirja wanted in the end.  It is no longer present
in -17, which is the latest published version of the draft.

Third, by being a macro, the parameter makes the information model
redundant.  Thuos, it is not clear what an implementation should announce
if its parmeterxes are set to values that don't match either the default
nor the fast convergece set.

I now recall why we made the other parameters read-only: it is perfectly
legal for an implementation to tweak them dynamically, depending on
network conditions or other data (such as battery load).  Thus, it is not
clear that it makes sense to make them read-write.  The same argument
applies to the proposed "fast-convergence" switch.

Thus, it is my opinion that such a switch should not be added to the
information model.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 27 Jul 2020 18:55:55 +0200

> Thus, it is my opinion that such a switch should not be added to the

I would tend to agree with your reasoning and conclusion.

-Toke

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 27 Jul 2020 22:23:20 +0000

Thanks y'all. I'm comfortable with your responses and will close that out.
Barbara

> -----Original Message-----
> From: babel <[email-masked]> On Behalf Of Toke Høiland-
> Jørgensen
> Sent: Monday, July 27, 2020 11:56 AM
> To: Juliusz Chroboczek <[email-masked]>; [email-masked]
> Subject: Re: [babel] Information model: fast-convergence
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_babel&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=g2rVU1U-LEyG-
> WHR5Fg6R7KWViUSggfrgxfvCTLIQMA&s=MPVW3N71R2of-
> pMbpPYvrk7QGd40ZIqVBryhCAGuPeY&e=

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 28 Jul 2020 17:39:49 -0400

Hi,

On Mon, Jul 27, 2020 at 12:00 PM Juliusz Chroboczek <[email-masked]> wrote:
> overhead. ...

Speaking as a WG member, I agree.

> accept the notion of a robust algorithm.

I do not think it has anything to do with non-acceptance of algorithm
robustness. I believe their thought process is more or less as
follows: If a parameter makes no difference, then it shouldn't be
called out at all or should just have a fixed value. If a parameter
does make a difference then, while this might not apply to
informational or experimental or research documents, for a protocol
standard there should be a recommended value or a method for
determining a recommended value.

As an example I recently saw, look at Section 14 (top of page 16) in
https://tools.ietf.org/html/draft-ietf-6tisch-msf-16 (I read this
draft because I was asked to review it as a member of the IETF
Security Directorate.) That document calls them "constants" rather
than "parameters" but it is the same thing and the draft has a table
of their RECOMMENDED values. It is what people want and expect in a
protocol standard, at least in the IETF and in IEEE 802 where I have
the most experience.

>                                       Please ignore this recommendation,

A recommended value is just that: only a recommendation.
Implementations are free to use other values and will still be
conformant to the standard.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 33896 USA
 [email-masked]

> ...

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 29 Jul 2020 02:50:04 +0200

> conformant to the standard.

    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
       may exist valid reasons in particular circumstances to ignore a
       particular item, but the full implications must be understood and
       carefully weighed before choosing a different course.

This is a quite a bit stronger than what you describe, which is why
I attempted to convince the IESG that "example values" should be used
instead.  I find it unfortunate that I didn't manage to get through.

Perhaps we should be using the terminology defined in RFC 6919:

   1.  MUST (BUT WE KNOW YOU WON'T)

       The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate
       requirements that are needed to meet formal review criteria (e.g.,
       mandatory-to-implement security mechanisms), when these mechanisms
       are too inconvenient for implementers to actually implement.

       This phrase is frequently used in a contracted form in which the
       parenthetical is omitted.

-- Juliusz