Subject: [babel] reliable route transfers

From: Dave Taht <[email-masked]>
Date: Tue, 28 Mar 2017 09:04:57 -0700

I haven't got so far as to inspect what this would do to the base
specification (at minimum there would need to be a message or flag
saying "contact me at ip address X (using pub key y) if you can"),

but I have a prototype sort of running that does route transfers via
rsync over ssh to port 6696.

This solves the congestion control problem with route updates :thoroughly:. :)

Alternatively I was fiddling with using the "ack" message to try and
better rate limit route updates.

The easy way to expose this problem is to try running the "rtod" tool
on any slow (1mbit) network, with a few thousand routes. (it tends to
break all the meshy protocols and comes with dire warning attached)

https://github.com/dtaht/rtod

-- 
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: Tue, 28 Mar 2017 12:25:25 -0500

> better rate limit route updates.

Right.  The current reference implementation doesn't pace route updates --
it sends a whole periodic route dump as a burst of as many packets as
needed, rather than staggering updates across the update interval.  So
even increasing the update interval will not alleviate the amount of data
being sent as a burst.

I'll see if I can hack together a solution on the plane.  It's not
entirely obvious how to do it cleanly -- right now, the update deadline is
a per-interface datum, it would need to become a per-(route,interface)
pair one.

Toke, how does your implementation schedule periodic updates?

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 28 Mar 2017 19:40:59 +0200

> Toke, how does your implementation schedule periodic updates?

Same as babeld (i.e., it doesn't, it just dumps everything at once).

-Toke

---

From: Dave Taht <[email-masked]>
Date: Tue, 28 Mar 2017 13:23:30 -0700

> even increasing the update interval will not alleviate the amount of data

Yes. basic tcp friendliness would be good here.... and burstyness to
some extent is also desirable for 802.11 aggregation.

> a per-interface datum, it would need to become a per-(route,interface)

The point of confusion for me in the spec was that each route is
associated with an interval (currently) closely associated with the
hello timer.

There will always be a point (RFC970) at any bandwidth, where you have
more routes than you can get out in any given hello interval, and
either discarding them (intelligently), or pushing forward
(increasing) their potential update interval to something that can be
expressed within that bandwidth seem like answers, while still
adhering closely to delivering hello packets within their interval.