[PATCH v2 2/2] Add the Babel protocol.

[Ondrej Zajicek]

On Sun, Jan 17, 2016 at 12:19:08PM +0100, Toke Høiland-Jørgensen wrote:
> Juliusz Chroboczek <jch at pps.univ-paris-diderot.fr> writes:
> 
> > Please don't make this configurable, it only breaks interoperability.
> > Section 4 of RFC 6126 is very clear about the maximum size of a Babel
> > packet:
> 
> Noted. Snatched that from the RIP implementation; thought it might be
> nice to be configurable in the same way. Guess I was wrong... ;)

Hi

I still prefer to keep these options in the code. They are consistent
with options in RIP and OSPF interface statements and although bad usage
of these options may break compatibility, they are useful for handling
some exceptional situations.

Some examples are interoperatility with potential broken implementations
(there is a RIP implementation that sends packets of size 560 although
maximum per RFC is 540), networks where optimal packet length is lower
than IP MTU (some tunnels or networks with L2 fragmentation), or
situations where BIRD does not properly account for IP overhead because
of admin-configured IP options like IPSec).


Although the code should use proper length from RFC by default, so the
function babel_iface_update_buffers() should do:

  uint rbsize = ifa->cf->rx_buffer ?: MAX(ifa->iface->mtu, BABEL_MIN_MTU);
  uint tbsize = ifa->cf->tx_length ?: MAX(ifa->iface->mtu, BABEL_MIN_MTU);

Instead of

  uint rbsize = ifa->cf->rx_buffer ?: ifa->iface->mtu;
  uint tbsize = ifa->cf->tx_length ?: ifa->iface->mtu;


Where BABEL_MIN_MTU is 540 (512 adjusted for IP and UDP headers).



> >> +static struct babel_source *
> >> +babel_find_source(struct babel_entry *e, u64 router_id)
> >> +{
> >> +  struct babel_source *s;
> >> +  WALK_LIST(s, e->sources)
> >> +    if (s->router_id == router_id)
> >> +      return s;
> >> +  return NULL;
> >> +}
> >
> > We've recently found out that in large networks, a large amount of CPU
> > time (40%) in babeld was taken by walking the source table -- I recommend
> > using a more efficient data structure here.  (Source creation/flushing is
> > rare, but searching for a source is very common.)
> 
> Yeah, saw that thread. Punted on doing something about it here; guess
> I'll see if I can figure out how the Bird hash table works... Bah! Who
> needs such big networks anyway?

I did not read mentioned thread, but note that here the function
babel_find_source() iterates only through sources for one propagated
prefix. So the problematic situation is a big L2 network with many
associated routers in it, propagating the same prefix for it?



I have one more general question. Is ETX cost algorithm really a
reasonable idea? It seems to me that in many cases it will lead to
oscillations, because packet loss in wireless networks usually depends on
traffic load. It seems to me that dynamic cost algorithms based on packet
loss should at least use some hysteresis.


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20160117/85329b89/attachment.asc>