Re: What was the Chameleon disaster?

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
<[email protected]> 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 <[email protected]> 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
>

_______________________________________________
manet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/manet