Subject: [babel] first message?

From: Alia Atlas <[email-masked]>
Date: Wed, 5 Aug 2015 13:58:33 -0400

Hi,

I see that this mailing list has 44 subscribers.  One of the key questions,
of course, is whether there is an active and energetic community of people
interested in doing the work to potentially standardize Babel.

>From the side-meeting, a point of having a mailing list was to discuss and
clarify the potential applicability of babel, the motivations for
standardizing it, and the work to be done to bring Babel to a proposed
standard.

Regards,
Alia

---

From: Henning Rogge <[email-masked]>
Date: Mon, 10 Aug 2015 10:31:22 +0200

Hi,

the Babel developer team (and quite a few people interested in Babel
including me and Dave Taht) were on the Battlemesh
(www.battlemesh.org) in Slovenia last week... where we did tests with
5 mesh routing protocols including Babel.

so I expect the amounts of mails here to increase in the future.

Henning Rogge

On Wed, Aug 5, 2015 at 7:58 PM, Alia Atlas <[email-masked]> wrote:
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Aug 2015 08:58:37 -0400

One of the comments I saw from the battlemesh discussion is that the babel implementation that Juliusz has done has substantial tweaks to deal with the startup problem he described on WiFi networks.   Are those tweaks documented in the current specification?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 10 Aug 2015 20:45:04 +0200

> One of the comments I saw from the battlemesh discussion is that the
> babel implementation that Juliusz has done has substantial tweaks to
> deal with the startup problem he described on WiFi networks.  Are those
> tweaks documented in the current specification?

I wouldn't call them substantial tweaks -- they are just two tradeoffs
between spam and fast convergence that I had gotten wrong initially.  (It
took me a long, long time to understand that theoretical convergence speed
is not the primary concern -- not breaking the medium is more important
than the theoretical worst-case convergence time.  Yeah, seems obvious in
hindsight.)

Concerning the noise at startup, RFC 6126 only has the following to say
(Section 3.8.2.4):

   In order to speed up convergence after a mobility event, a node MAY
   send a unicast wildcard request after acquiring a new neighbour.
   Additionally, a node MAY send a small number of multicast wildcard
   requests shortly after booting.

What I've learned since RFC 6126 was written is that a node SHOULD NOT do
that, at least not without implementing some other mechanism to avoid spam.

Additionally, 3.8.1.1 says

   When a node receives a wildcard route request, it SHOULD send a full
   routing table dump.

What is missing here (which I didn't know at the time) is that the full
route dump MAY be sent over either unicast or multicast, and that
multicast full table dumps MUST be rate limited.  (The current
implementation uses multicast, and does do rate limiting.)

As to the jitter, RFC 6126 is pretty clear.  Section 3.1 says

   The exact delay and amount of jitter applied to a packet depends on
   whether it contains any urgent TLVs.  Acknowledgement TLVs MUST be
   sent before the deadline specified in the corresponding request.  The
   particular class of updates specified in Section 3.7.2 MUST be sent
   in a timely manner.  The particular class of request and update TLVs
   specified in Section 3.8.2 SHOULD be sent in a timely manner.

and the informative appendix B adds the following:

   The amount of jitter applied to a packet depends on whether it
   contains any urgent TLVs or not.  Urgent triggered updates and urgent
   requests are delayed by no more than 200 ms; other TLVs are delayed
   by no more than one-half the Hello interval.

I think this section should contain some words of caution about reducing
the 200ms constant, at least on some media.

(Editorial note: the document is not quite clear that the "urgent" TLVs of
Appendix B are the ones that are sent "in a timely manner" in the body of
the document.)

Finally, RFC 6126 allows both unicast and multicast operation, and allows
both unreliable and acknowledged communication.  The current implementation
uses multicast almost exclusively, and doesn't use any acknowledged packets;
I still need to experiment with the alternatives.

I'd be cautious about making anything of the above normatively constrained,
since Babel interoperates just fine with differing time constants and
emission strategies, and I am optimistic that the algorithms of the
current implementation can be improved more.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Mon, 10 Aug 2015 18:42:35 -0400

> current implementation can be improved more.

It seems reasonable to say "here are the parameters that we know work in practice, here are some examples of problems that occur if you use values more in this range, and we think that further tuning is possible," rather than making normative requirements, then, right?