[PATCH] babel: Keep separate auth PC counters for unicast and multicast

[Juliusz Chroboczek]

>> The issue has been described in draft-ietf-babel-mac-relaxed, which is
>> currently pending RFC publication. That also describes two mitigation
>> mechanisms: Keeping separate PC counters for unicast and multicast, and
>> using a reorder window for PC values. This patch implements the former as
>> that is the simplest, and resolves the particular issue seen on WiFi.

> Is that sufficient?

Babel is designed to work well even with very high rates of packet loss.
If the link routinely reorders packets, the receiver will drop the
reordered packets, but Babel will recover.

Obviously, though, Babel cannot handle systematic packet loss (where the
same packet is systematically lost even if it gets resent).  The case that
this mechanism aims to solve is the case where multicast packets are
systematically delayed, and therefore dropped by the receiver, even if
they get resent.

> In general, one should not assume anything about link frame
> ordering. Even two unicast (or two multicast) packets can be reordered
> due to e.g. frame retransmission.

The packet that was retransmitted at the link layer will be dropped by the
receiving node, then resent by the application layer.

> I think that simple sequence numbers work in two cases - if there is
> sufficient interval between packets, or there is only one packet flying
> (e.g. LSREQ-LSUPD ping-pong in OSPF). That is approach used in OSPFv2 and
> OSPFv3, but that is not true in Babel.

Agreed: the occasional dropped packets may slow down reconvergence, but
they won't prevent Babel from reconverging in the end.  Unlike the
systematic issue that this patch solves, and which may prevent
convergence.

If that's okay with you, Ondřej, I would recommend applying this patch,
which is necessary for correctness, and worry about efficiency at some
later time.

-- Juliusz