Re: [manet] What was the Chameleon disaster?

[Christopher Dearlove <[e-mail]>]

My view on a hybrid protocol took that further, but started as you say. One can view
willingness to be an MPR (even separately for routing and flooding) as a policy as
to what the router is prepared to do (easier to consider it binary as a starting point).
Then, coupled with ideas of using a reactive RREQ/RREP mechanism as a supplement
to the HELLO/TC mechanism, you can consider more general policy as to what a
router is prepared to do. Maybe not prepared to send periodic messages, but prepared
to forward RREQ/RREP messages, because administratively we have decided those
are important. Or add a priority indication, thus making this, like willingness, not binary.
Or many other possibilities, but that’s design.

> On 16 Oct 2023, at 07:18, Henning Rogge <[e-mail]> wrote:
> 
> For me the challenge in hybrid protocol is similar to the challenge of
> a good OLSRv2 MPR algorithm. You want to have the ability for nodes to
> completely (or nearly) sleep for some time, only doing work for
> themselves, but you still need a well working total network. Which
> means you need an algorithm that is good for both local and global
> optimization, but don't fail when the amount of available information
> drops (because some nodes don't provide global data anymore).
> 
> In theory OLSRv2 can become a "semi-hybrid" protocol just by not using
> certain nodes as MPRs for anyone, which means they only need to
> participate in the HELLO protocol part (which is much cheaper than
> forwarding TCs and data). But it's quite challenging to do so with a
> distributed algorithm, especially when a change in topology might
> force you to "re-awaken" certain nodes.
> 
> Doing this "by configuration" is trivial, just set flooding- and
> forwarding willingness of an OLSRv2 node to "never".
> 
> Henning Rogge
> 
> On Sun, Oct 15, 2023 at 10:42 PM Christopher Dearlove
> <[e-mail]> wrote:
>> 
>> Sorry, I don’t see what you mean by “announce a route to self” and how it helps. The hypothetical router that’s not joined the proactive network isn’t even known to exist by the other routers, because it has not joined their network. And that’s in the simplest of cases, where it is just one hop away from a proactive router and could - with some new signalling, just join enough to make it that router’s problem. But things can get more general than that.
>> 
>> But it isn’t really important, as the key point is needing a use case. A hypothetical one - several in fact - is not trivial but not hard. But you need more than hypothetical to even know which of those would be worth pursuing. And I don’t see anyone offering that.
>> 
>>> On 15 Oct 2023, at 20:54, Juliusz Chroboczek <[e-mail]> wrote:
>>> 
>>>>>> which usually does, and should, mean real use cases
>>> 
>>>>> Ok, I'll bite.
>>> 
>>>>> What are the use cases for a hybrid protocol that are not satisfactorily
>>>>> met by existing protocols?
>>> 
>>>> Answering that question would be step one.
>>> 
>>> Agreed.
>>> 
>>>> In that hypothetical spirit, let’s suppose most users are happy with
>>>> a proactive protocol. But there are a few who, due to need for
>>>> covertness, or limited battery life or whatever don’t want to join
>>>> in. But occasionally they might have a need to communicate. So are
>>>> prepared to reactively establish a connection.
>>> 
>>> At that point, they announce a host route to self, and point default at
>>> a neighbour that announces a default route.
>>> 
>>> https://www.rfc-editor.org/rfc/rfc8966.html#name-stub-implementations
>>> https://github.com/jech/sbabeld
>>> 
>>>> Or maybe they are prepared to accept such a connection.
>>> 
>>> In this case, you need a protocol extension that requests a node to
>>> announce a route to self.  It should not be too onerous to define, but I'd
>>> like to convince myself there's an actual need.
>>> 
>>> A use case for a true hybrid protocol would be somewhat more difficult to
>>> construct, it would probably involve a node that doesn't need continuous
>>> connectivity but at the same time can occasionally serve for transit.
>>> 
>>> We, at Babel Towers, are of course always interested to hear about novel
>>> use-cases for routing protocols.
>>> 
>>> -- Juliusz
>>