[manet] General thoughts on OLSRv2 and WG items

Christopher Dearlove <christopher.dearlove@gmail.com> Tue, 26 September 2023 14:35 UTC

Return-Path: <christopher.dearlove@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C73C151999 for <manet@ietfa.amsl.com>; Tue, 26 Sep 2023 07:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.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_HI=-5, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hpc6dTjWzfWV for <manet@ietfa.amsl.com>; Tue, 26 Sep 2023 07:35:39 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 7B1F8C15198E for <manet@ietf.org>; Tue, 26 Sep 2023 07:35:39 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-31f7400cb74so8151485f8f.2 for <manet@ietf.org>; Tue, 26 Sep 2023 07:35:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695738937; x=1696343737; darn=ietf.org; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:from:to:cc:subject:date:message-id:reply-to; bh=ym2vnT/qskgEdJl+NLmpIV8HNJbW99zaclowz68I6Og=; b=ec3RvFvQdZwSmvbOHQS03eFEf8OG09AQfOYJNqjE9kdH4CGqQhpYg/LLhPC2t/db5S sF7eDcOWfvObHhaiMfwddGjcUtVifGRbspVUOFt8cLCkpocSoXQqYNOh/D1HdLScCaOI X16BiRykLyDI1IVMQYr/CeqqmDOvcbuswh4Mjj/XdKx85DsG+X4g1l5Zru/WUX1TUTgJ VaLm1nUhSzA/H5vq3X61OwbnlZiqqtaKJYRT+ybz9Alu9DV6b6gbffrfp0gthCuNLGL6 0fYlVKF3vDwI7WQwzG52sgh71AkBQu67NN70PUCuJ94ClQFFtp09ACbT25XW8tMPSQHo HVHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695738937; x=1696343737; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ym2vnT/qskgEdJl+NLmpIV8HNJbW99zaclowz68I6Og=; b=mkpTWR6bgpKZA7K3H1TNbcKhKgr9yUqt5w3WTV7TXiNWiusaTEQXuawLRuqDpPGkVj B1t4dKge1opCHWmZWrqAEL8YDDq7qI1irLxkkcDE85aTSdsKLCU+nHF5P/AMbMjcywrk b05wKO8C+nqLzwanaOrzdMPPVH7+f1rsJEQpe/w8WpGnxGxeABiw+ULwIVDkNbq7QGc3 i0Jw+S/e6d9NKu1MWWyYXX8nw34S0nUjUGqcGzvZ1bETEBhcgBqkQAZOlyPIQcWwVBH6 4Gk9/0/qY6oRV8cuo93K6ooXP2Mci5yzy2Vrh9XWvDeeSID7NU8TgDpgANO5gJCKUECv EgYQ==
X-Gm-Message-State: AOJu0YwYzGFx/wBfaUgfK9vChYnhAIE0Y/9Oc0BQFIq4g1ndOOJyCG++ mggiCYk5ZoWMY4Q41LvFqLlPFnlvP8A=
X-Google-Smtp-Source: AGHT+IEgJNl0mm8mRpO8YRS/YDpuc6hsFHKONidboN6oi/szyAhkovumscXO7EJrq2YlbUmGkAxEdg==
X-Received: by 2002:adf:ec42:0:b0:31f:fb63:12d8 with SMTP id w2-20020adfec42000000b0031ffb6312d8mr8253582wrn.44.1695738937083; Tue, 26 Sep 2023 07:35:37 -0700 (PDT)
Received: from smtpclient.apple (82-132-225-118.dab.02.net. [82.132.225.118]) by smtp.gmail.com with ESMTPSA id a3-20020a5d5083000000b003198a9d758dsm14937381wrt.78.2023.09.26.07.35.36 for <manet@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Sep 2023 07:35:36 -0700 (PDT)
From: Christopher Dearlove <christopher.dearlove@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Message-Id: <62ABFD69-3EF6-4C9E-B7A2-5C59D57CC4E0@gmail.com>
Date: Tue, 26 Sep 2023 15:35:21 +0100
To: MANET IETF <manet@ietf.org>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/4D4vnxUSUc3Mot63RKCXa6cN6mo>
Subject: [manet] General thoughts on OLSRv2 and WG items
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Sep 2023 14:35:43 -0000

Note that I am retired (early) from BAE Systems - so don’t try using the email address in RFCs. It means I do not have any real customers or practical application at this time. Any participation would thus be limited as I will indicate. It also, unfortunately, means I don’t have access to the (complete - even up to RFCs 7722 and 7859) implementation that I wrote, and getting access is unlikely.

We never, unfortunately, wrote an informational RFC that explains why various options - arguably too many - exist in OLSRv2. As such I think some of its capabilities are not always apparent. Whether anything should be done - piecemeal or collectively - is, as usual, something needing work. Here I’ll highlight what I think are the less obvious features that could be described informationally:

- The ability to use OLSRv2 in what we have referred to as a responsive manner (the word reactive being otherwise used). Essentially this means that instead of sending HELLO and TC messages periodically, they are sent on startup and in response to changes. I have more to say on this, which will be in another posting.

- The ability to use “fisheye” routing where short distance messages are sent more often than long distance ones. The intent is a reduction in overheads for (in some networks) little or no loss in performance.

- Differently and dynamically parameterised routers - a simple example being to send messages more frequently if faster moving, another being having markedly different interface types.

- There are some features that can be used to advantage, such as overhead reduction by combining messages in packets aided by jitter.

In terms of new items, if anyone wants to take multitopolgy OLSRv2 to standards track - especially if not planning major changes - I could support that. But I couldn’t justify trying myself.

I’ll also just mention a hybrid protocol. This is a significant undertaking, just to be experimental, and without my implementation of OLSRv2 I wouldn’t be able to be a significant mover in that. I have previously done some preliminary work (the actual work is not available) on this. The basic idea would be to add AODV-style RREQ and RREP messages to OLSRv2 (you want to implement it that way) to find a destination when one is unknown, using the established network to help. (However, beware, there’s a problem doing the most obvious thing.) To be useful I would take it further into a policy-based approach. Each router would have a policy as to what it is and is not prepared to do. Note that this already exists in OLSRv2 in the form of willingness. If you only consider willingness zero/nonzero we have the router’s policy “am I prepared to act as an MPR?, hence am I prepared to flood messages? Am I prepared to relay data packets? Now we have issues like “am I prepared to join the proactive part of the network?” and the same willingness questions, only for reactive routes. Well-designed, the protocol would collapse to pure OLSRv2 or a pure reactive protocol (I would suggest the simpler LOADng) if all routers chose accordingly.

Christopher Dearlove