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

[Toke Høiland-Jørgensen]

Juliusz Chroboczek <jch at irif.fr> writes:

>>> 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?
>
>> Yes.
>
> [...]
>
>> Oh, and the reason we don't need to keep track of all neighbours is that
>> when we satisfy a request we just trigger a global (multicast) update
>> for the prefix instead of sending it individually to all neighbours we
>> forwarded requests on behalf of.
>
> Right.  Babeld does the same.
>
> But in that case, I don't understand why you need to keep track of the
> neighbour in the first place.  I haven't looked at this code in some time,
> but I seem to recall that in babeld, we simply retain the information that
> there's a pending request, we don't need to know on whose behalf it's
> being made.

Right, so after going after this a couple of times, I think I see the
discrepancy here: in Bird we're currently doing retransmission at every
hop; so since we're also retransmitting a request that we're forwarding,
we need to keep track of which neighbour it came from so we're not
sending it back to the originator.

But reading the sections in the RFC again I can see how the section on
forwarding doesn't actually say anything about retransmitting; and I
guess it does make more sense that it's just the originator who does
retransmission. So if we're just doing forwarding as a one-off then
you're right, we don't need to keep the originating neighbour around.
That should simplify things some :)

>> Hmm, right, well my reasoning was also that receiving an unfeasible
>> update is not as "urgent" because we most likely have another route for
>> the same prefix that is feasible already. Or is this intuition not
>> correct?
>
> Consider the case of a well-connected cloud that is connected to the
> source through just one router:
>
>              B1
>            / | 
>           /  |
>   S ---- A --B2
>           \  |
>            \ |
>              B3
>
> If the metric of the route S-A increases by more than max_i(d(A,B_i)),
> then all of the updates sent by A become unfeasible for all of the B_i.
> Hence, all of the B_i remain unreachable until S originates a new seqno.
>
> A will forward a request on behalf of the B_i, and due to duplicate
> suppression, it will be forwarded only once.  If the request A->B is lost,
> then you're waiting until the next unfeasible update sent by A.


I this example will be covered by the starvation avoidance mechanism in
3.8.2.1, though? So do we really need to retransmit the unicast seqno
requests sent in response to an unfeasible update (section 3.8.2.2)? If
I'm reading the babeld source correctly it's not doing that either (nor
is it suppressing such one-off updates if there's already another
outstanding request)?

-Toke