Re: [manet] OLSRv2 futures

Christopher Dearlove <> Wed, 08 November 2023 15:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 405DDC17C539 for <>; Wed, 8 Nov 2023 07:15:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k72uRSnVsuMy for <>; Wed, 8 Nov 2023 07:15:25 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id B2E04C17C534 for <>; Wed, 8 Nov 2023 07:15:25 -0800 (PST)
Received: by with SMTP id 5b1f17b1804b1-408382da7f0so52029055e9.0 for <>; Wed, 08 Nov 2023 07:15:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1699456524; x=1700061324;; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ztrl6yOhQ75VbQj9hzsNu/j5sE86V4+Ulw9QO1ZmYtY=; b=M73sH9ZlcNj4StG8DH7ZVlo0mLdf5/jEGfqMrdftUOhWxb4/VU9/OfK0ZpgEsdaIxr p/dADuQrYVXpeGnDIQGi9HWbkug8qtlNew8N0Ri8HcXZYDVyRodFSEf1Uhudsx//mRnH 3ccJaJp7THT4lV3dFuCt0iI3Q+gWDzzWrRyvfuB71csKJqmphpePWcnCovC2dP4/gAba 4K5SY/dNr70RLbdH3sXBxk6V37X+VuxwwuQI9g0Zn5wKyE4nwPVbZ1FfemlMPqUC2zeI vP1Exxn7B2P7+eypdCDbRdu33jxK+ggFVHhQMSpKWhcQJ3vEpiDX3k7//aduTrP2jEw3 U7FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1699456524; x=1700061324; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ztrl6yOhQ75VbQj9hzsNu/j5sE86V4+Ulw9QO1ZmYtY=; b=QpU7beyY7XXe+0gtOz68qLyHC03F613LksY1debSrL7Xnfmt4qm0fJ0GgfJJnmSYuX tTCIOi3/tSuo5C3cBL+8PrUa4VznCWW0uh7BBqCQRyyfEd+sxZPKhmtCLxi+8VkS1Ydg YUHl+XArOvZjZYymFA1rWvuDHfPPYppD6t9ZyY+UUKBvOiOIcqcNYrRMz20fo9ZzrkdV 9xDRuCT7Xoe+VLHgsVHbny3pDixLB5YC4t0STMwsD0nIGYoFhbZ40YCKHUco7G60rz6k UeFENNB3dnVzTAirkgbayYgGccUFNIK0CWn9wWkjcA0ygZgs9SBWoWzlcHDa5YhQqmbA ohNw==
X-Gm-Message-State: AOJu0Yy7RrsEJnSMzgTjKlpMznOii4iW+LNKXOn1JcEurGwEnQfEnu9q OmNLfmVrLNMQzEPSOso3RmA=
X-Google-Smtp-Source: AGHT+IH1CtIaUwve+5Rbv6Nk++UsUVD2sMTL7gwqxr1FMAidDiWVrdY0+nkKhslGAy+mJz4TWdI+Sw==
X-Received: by 2002:a5d:6d06:0:b0:32d:89ca:1761 with SMTP id e6-20020a5d6d06000000b0032d89ca1761mr1806853wrq.43.1699456523464; Wed, 08 Nov 2023 07:15:23 -0800 (PST)
Received: from ( []) by with ESMTPSA id w26-20020adf8bda000000b0032dcb08bf94sm5146553wra.60.2023. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2023 07:15:22 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.\))
From: Christopher Dearlove <>
In-Reply-To: <>
Date: Wed, 08 Nov 2023 15:15:10 +0000
Cc: bebemaster <>, MANET IETF <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Henning Rogge <>
X-Mailer: Apple Mail (2.3774.
Archived-At: <>
Subject: Re: [manet] OLSRv2 futures
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Nov 2023 15:15:26 -0000

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 <> wrote:
> On Wed, Nov 8, 2023 at 2:34 PM Christopher Dearlove
> <> 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