Re: [manet] OLSRv2 futures

[Christopher Dearlove <[e-mail]>]

Yes, we had the should topologies be defined by metrics discussion at the time. The issue was one of backwards compatibility with the already standardised OLSRv2, how a non-MT-OLSRv2 router could coexist in an MT-OLSRv2 network. We couldn’t make a more general approach work in that way. We did try.

And, yes, agreed on the aggregation.

Incidentally, on aggregation, there’s another item I could have added to my list on efficient use of OLSRv2, which is making constructive use of RFC 5148 jitter to not just avoid collisions - its reason for existence - but to cut down transmissions. Here we assume that all messages of interest at any time will fit into an acceptable size packet. Modifications when they don’t are possible.

So if we have messages to be sent and messages to be forwarded, with jitter, each has a transition time that can be expressed as a window, from earliest to latest. Without any other messages to send or forward, you would pick a random time in that window. (Uniformly distributed with just the one message.) Now suppose we have two messages - maybe being sent, maybe being forwarded. Each has an intended transmission time in their windows, here assumed to be overlapping (as if not, just send). As a starting point let’s consider the windows to be the same. So each has a sending time. But when sending the first, why not piggyback the second? Because with OLSRv2 packet, UDP, IP, MAC, PHY headers and other effects, minimising transmissions is a definite win, even if the payload data size is not reduced.

 If the message windows only overlap, not coincide, you need to be more clever (given that you do not want to send a message outside its window (unless neighbours or parameters change and you respond to that). And if you want real subtlety - my implementation didn’t go quite this far - it’s not clear if this would be more work than any possible gain - you could adapt the choice of random point within a window to be non-uniform so that the earliest of two messages - which the other will piggyback on - is uniform rather than being biased early.

And of course the standard already suggests strongly that messages received bin a packet should be forwarded together, for similar reasons.

 Even fairly small networks, packets that aggregated perhaps a sent message (or two, HELLO and TC) and a few (I certainly recall three or four) forwarded messages in a packet was not uncommon.

You should restart message intervals when messages are actually sent. Plus take care of that if the neighbourhood (or parameters) change, that’s a possible reason to remove messages (actual messages, or just instructions to create message at that point) from an outgoing message queue.

Depending on how much detail you want to get into, that’s not trivial to specify correctly. Depends on how much you leave to the implementer (as I left various things vague above). And it’s all optional, counter-productive to attempt to standardise (beyond what 5148 and its use does).

[Incidentally, we should have made 5148 standards track, it being informative caused some hassle when creating 6130 and 7181, as technically it’s a downref.]

> On 8 Nov 2023, at 14:47, Henning Rogge <[e-mail]> wrote:
> 
> On Wed, Nov 8, 2023 at 2:34 PM Christopher Dearlove
> <[e-mail]> wrote:
>> 
>> 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.
> 
> Yes, that makes "per interface" TC rates/validities quite useless.
> 
>> 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 have implemented MT-OLSRv2 twice, it works well enough... I am not
> sure the "metric per topology" is always the best option, but it
> works.
> 
>> 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.
> 
> This would also remove quite a bit of aggregation that you get by
> combining data from all topologies into one TC.
> 
> Henning Rogge