Subject: [babel] route expiry timers for rebroadcast?

From: Dave Taht <[email-masked]>
Date: Sun, 19 Feb 2017 08:05:40 -0800

There is a possible hole in the spec here in that it doesn't clearly
describe what should be done with forwarding route expiry timers.

https://tools.ietf.org/html/rfc6126#section-3.5.4

   When a route's expiry timer triggers, the behaviour depends on
   whether the route's metric is finite.  If the metric is finite, it is
   set to infinity and the expiry timer is reset.  If the metric is
   already infinite, the route is flushed from the route table.

   After the routing table is updated, the route selection procedure
   (Section 3.6) is run.

The corresponding 3.7 section for advertisment says:

"   If an update is for a route learned from another Babel speaker, the
   router-id and sequence number are copied from the routing table
   entry, and the metric is computed as specified in Section 3.5.2."

where it would make some sense to also bound the client router's
recieving that update to rebroadcast advertising the interval field to
some amount less than the received interval, or to the actual
bandwidth available on an interface, but still broadcast as
catch-can...

...

I ran into this issue while trying to distribute 20,000 routes over
1Mbit multicast to a dozen routers - don't do that on a production
network!

http://www.taht.net/~d/gentleremindertogetridoftheinfinitemcastqueueinlinux80211.png

Incast burp. Consider yourself warned! but "an" answer to that is to
start spreading the expiry interval out as you carry more routes than
available bandwidth and update interval can take.

Although the reference implementation lets you modify the hello
interval, it always derives the expiry timer directly from that,
rather than based on the load.

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 20 Feb 2017 03:31:23 +0100

> bandwidth available on an interface, but still broadcast as

I think there's some confusion here.  These are two distinct timers -- the
route expiry timer (Section 3.2.5) and the update timer (Section 3.2.2).
The route expiry timer is governed by the Interval value advertised by the
peer (last bullet point in Section 3.5.4), while the update timer triggers
at fixed intervals.

There is indeed an omission in the spec -- Section 3.7.1 does not
precisely say how to deal with the update timer, it merely says that the
updates are sent periodically.  As you justly guessed, the protocol is
robust enough to allow varying the period depending on external factors
(e.g. network load), but finding the right heuristics is probably an open
research problem -- the only thing that rings a bell is the pacing of
refloodings in IS-IS, but that's a very different issue from pacing
updates in a distance vector protocol.

-- Juliusz