[PATCH] babel: Rework seqno request handling to track sender, not destination

[Juliusz Chroboczek]

> Tying the seqno request entry to the destination had the problem that when
> that destination neighbour entry was removed, we'd remove the entire
> request, and thus no longer retransmit it. Tying the entry to the neighbour
> on whose behalf we are forwarding the entry instead means that we can just
> clear out the neighbour from the request entry when we're removing it, as
> long as we keep a separate flag specifying that it's a unicast request.

This paragraph is not entirely clear to me.  Do you mean that the
neighbour on behalf of which we're forwarding the request has gone away?

> Rather than complicate the request tracking, we just change the requests
> sent in response to an unfeasible update to be one-off unicast messages
> without any retransmission tracking. This should be OK, as we'll send
> another request the next time we receive the unfeasible update anyway.

Note however that Babel is designed to run reasonably well with very large
update intervals, so the next unfeasible update might not be coming soon.
I agree that the request tracking is the most complex part of Babel,
though, so it makes sense to take some shortcuts.

(Actually, the protocol was designed so that all the intervals (Hello, IHU
and Update) can vary dynamically, and it would make a lot of sense to
increase the Update interval when we detect a large, stable network.)

-- Juliusz