Re: [manet] OLSRv2 futures

I’m fairly sure we considered that, but decided against that. The issue is that TC messages are forwarded, and don’t stay on the sent interface (if that’s even a meaningful concept). So if we sent TC messages at a different rate on different interfaces, that would only apply for one hop, thereafter the interface and the interval would be decoupled. So now we need to know why the idea, in order to decide what the point is.

So, hypothetically, let’s au we have two interface types - and that’s a new, non-trivial, concept - I and J. Router A wants to sent TC messages more often on I, perhaps because it’s less reliable. So we send at two different rates. Now we have to decide when a new router A receives those messages what to do with them. In the simplest case it also has the same two types of interface. So just forward on matching interface types? Maybe - though I’m not sure even this case doesn’t have problems. But now let’s suppose this new router B just has interface type I. If it only forwards the interface I TC messages, it’s going to create a network with lesser connectivity than it could have - a further router C that only connects to router B via interface type J won’t get the TC messages, and will be disconnected.

So if we say we forward always, what are we achieving by sending at two rates? And if we want a split topology, we already have (experimental still) MT-OLSRv2 to use.

I also would need to investigate MPR behaviour. There’s a not well understood (I think) condition on why MPR forwarding works and doesn’t block. (It assumes sequencing - I didn’t discuss a rationale document that could include this.) Is this still valid here? Probably, but I’d need to check.

tl;dr - there are some definite issues here, which means I don’t think that’s going to work. But first, what’s the rationale, as that might either suggest how to do it or why not to do it.

Looking at RFC 7722, it doesn’t have message intervals per topology. I was going to suggest it could - and changing an experimental protocol is easier than changing a standard - but there are some issues there I think. But again, rationale.

> On 8 Nov 2023, at 13:06, bebemaster <bebemaster@gmail.com> wrote:
> 
> Pretty good list. If we are looking to modify OLSRv2 having variable  sending/forwarding TC rate per interface would be high up on my list of things to add, and perhaps not trivial.
> 
> Justin
> 
> -------- Original message --------
> From: Christopher Dearlove <christopher.dearlove@gmail.com>
> Date: 11/8/23 7:55 AM (GMT-05:00)
> To: MANET IETF <manet@ietf.org>
> Subject: [manet] OLSRv2 futures
> 
> To summarise where I think things are with regard to OLSRv2, starting from the easiest - not necessarily the most important (if anything is).
> 
> - A simple standards track document that adds permission to for a router to send one or more unscheduled TC messages (probably changing schedule) on learning of a new router in the network (on adding an entry to the Advertising Router Set). However, a complication is that the motivation for this is based on the next item, so how to package the two would be an issue, as there’s a standards track/informative mismatch. Probably end up repeating some material.
> 
> - An informative document that explains how OLSRv2 (including NHDP) can be used in ways that allow more efficient use in some scenarios. I have notes somewhere that can expand on some of this. It could be considered as rationale for many of the design decisions. A possibly non-exhaustive list of these features and use is:
>   + The ability to work responsively, only sending messages when the situation changes. (This might need the first point above for ideal use.) Assumes a stable network, other than joiners/leavers and the changes they offer/require, and the ability to recognise local changes. (Or continue to use NHDP as usual.)
> + The ability to change parameters dynamically. Enables features such as exponential backoff in stable circumstances, with reversion when changes occur. Similar to the above in some regards.
> + Different parameters on different routers and different interfaces. The former is potentially useful when e.g. some routers are moving rapidly. Ideally some modelling would support this.
> + The ability to set multiple TC interval times at different distances, implementing the concept of fisheye/HSLS routing. Requires some, not easily defined, network properties to be suitable (density largely).
> 
> From this point down, there needs to be real motivation to consider them. (Also true above, but I think that might exist.)
> 
> - A mechanism to allow a forgetful router to rejoin a network without waiting for timeout of its previous messages. Ranked lower than the above because it’s a change, and compatibility has to be considered.
> 
> - A mechanism to allow a router to dump its topology information to a new neighbour for fast full joining. There are lots of questions here - solicited or unsolicited, message format (and how to make 5444 compatible when it expresses the relationship between two addresses, not a characteristic of one address), in HELLO message?
> 
> And a long way down, and I don’t think there’s enough commitment from the WG, or even real use cases openly demonstrated:
> 
> - Adding reactive features (RREQ/RREP messages) to OLSRv2. In principle this wants a reactive protocol, but as so much would need re-engineering, knowledge of AODV/AODVv2/LOADng might suffice. Although the technical problems with AODVv2 remain issues to be solved here. The basic concept is routers not prepared to do what’s needed proactively (though this has more than one level) but prepared to do some or all of the work reactively (also more than one level). The full generalisation is a form of policy-based routing.
> 
> - Adding DTN features, with message store and forwarding. (I’m aware of some IPR here.)
> 
> - Routing confidentiality. (I’m aware of some IPR here too.)
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet