[manet] Problems not reports (was Re: AODVv2 implementation)

Abdussalam Baryun <abdussalambaryun@gmail.com> Sun, 28 January 2024 22:49 UTC

Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2B8D0C14F6A0 for <manet@ietfa.amsl.com>; Sun, 28 Jan 2024 14:49:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.104
X-Spam-Status: No, score=-6.104 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, FREEMAIL_REPLY=1, HTML_MESSAGE=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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id j3_1ms162MeB for <manet@ietfa.amsl.com>; Sun, 28 Jan 2024 14:49:46 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 3DB60C14F69F for <manet@ietf.org>; Sun, 28 Jan 2024 14:49:46 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-33aef64f702so92088f8f.3 for <manet@ietf.org>; Sun, 28 Jan 2024 14:49:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706482185; x=1707086985; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZC6XLvPA+Vm2AFPCk7a0m/0fmuB5R3P3KdhzL/M3o8E=; b=jXS8SrYk5XVD2TO1FSxytBLr6z4NNUBYEeDb2X53a8hQzitnfruNsGoBTCHOIBRuEO ziZJxgSdxs2pfILTueyQEuldOO/jKs7ct/ZcRNVCdDXFo4PfIEqLYVXhaets60zdqy16 krsxAlGlSWLTYbMPH0VigpR4vGiQRdXz5Ov8kWI/IYhpa2j0zWwcFEl+dVecf9Mco1Ui LVlKcTSELA0O+c6o3kG8BfgH0Tp+f8R1vR1CxILHhLLkodac0IwLdjdb/anUQY2uSeT+ egtGjiDTrHAJgOGZkOotJOxOnjmvNMRWDeUVYhgi9SVB1XSd6KTDlfdWaPjL4lf9awCn yc0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706482185; x=1707086985; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZC6XLvPA+Vm2AFPCk7a0m/0fmuB5R3P3KdhzL/M3o8E=; b=Y95Fhk1gl0Y2zYx7jzmNDXBBKETqy1Jr5rE+7WPJVINAJxwZHxpUUuK6VK2wJz7Nf8 X2UN9YnKrEC3Y17GPGzmNw143tcjXL7c6hN6+UsYQDq7MbH9yPiRxHx9naqYnEyXB+7K H1pd7ssL5zu8CLKFoynC/xqbL8arKf1mD5+OFFYDuXkNiYqdxLaq+yAhxt0AuGYhN/1u 7l2eDErhbvD24279Yrmi8MFlj+9h/YRoZa66vzzhwGbSUjCW/cFj8JEH75P6oBWyyGW2 t9ZFWy37vytHvMKUxM/9ZqdQExQAXbiJpvkY+pEo/E5taTFXi96sXE6pf48x+6KfLvZ6 r2bg==
X-Gm-Message-State: AOJu0YymSeyhVuR2wY/Y/g6TNvdep6+I0ihCBBjzCUFnVWsjOtDNwtm7 6gX1HNk61QV0XqbVTAwggDwvHwWRCg0YB8uOnkE6BC4GOlytlo2x/3u9W5x2P42Dh4kQLI/17oh jXILXy+gPKztkGJ9XD7he2aP1D7k=
X-Google-Smtp-Source: AGHT+IFevBQqs2qLlpsbnqXz2CQ9iW5Kbx2Yi4C3OMIz8DDsBhrt8flpisOWI8qF28+wboBPh6+WpmRXC5HUsqRAijc=
X-Received: by 2002:a5d:4568:0:b0:33a:e2f6:b5e1 with SMTP id a8-20020a5d4568000000b0033ae2f6b5e1mr3343759wrc.62.1706482184616; Sun, 28 Jan 2024 14:49:44 -0800 (PST)
MIME-Version: 1.0
References: <PH7PR14MB5368D3F677021CAFA04831F4BBB1A@PH7PR14MB5368.namprd14.prod.outlook.com> <740cf920-605d-4376-9db5-4409794bedb0@computer.org> <CAGnRvur98cmOqrB6b7Q=VsfvrBEY9goWn-zrXWM49mCj-+7zPw@mail.gmail.com> <7334e18e-d2aa-4f99-b79c-869b7ee1c836@computer.org> <87h6l9oqdk.wl-jch@irif.fr> <CAGnRvur17OvFogQnJspv=2ezuE41LQkgj5fEv5mJRGG9iYxZDw@mail.gmail.com> <CAL95ndJoFOay1Spin5vMfZV5KMHO5DkG7KhyHNo6KuAC3vm74w@mail.gmail.com> <875y1mgc9g.wl-jch@irif.fr> <CAGnRvurA7rg1R74-S4OgmFBE-3dqtgurF2=dGqYo69WMn6ynyA@mail.gmail.com> <B7D07985-DE8C-4B50-81FB-2CA00161CD4B@nrl.navy.mil> <CAF4+nEHJzC4wo4+Ht-PynovdLBsSAMLCycrf4aL0KUABndXm9Q@mail.gmail.com>
In-Reply-To: <CAF4+nEHJzC4wo4+Ht-PynovdLBsSAMLCycrf4aL0KUABndXm9Q@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Mon, 29 Jan 2024 00:47:15 +0200
Message-ID: <CADnDZ8_31gC5MEziOGGa0EPA+77KcRahgquwrY++FvgVRmVJuA@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Cc: "manet@ietf.org" <manet@ietf.org>, Juliusz Chroboczek <jch@irif.fr>
Content-Type: multipart/alternative; boundary="0000000000006dfcfd061009580d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/Hb-dizX1sBkJe5nkGl0sgp2Pu5g>
Subject: [manet] Problems not reports (was Re: AODVv2 implementation)
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: Sun, 28 Jan 2024 22:49:47 -0000

On Thu, Jan 25, 2024 at 8:07 AM Donald Eastlake <d3e3e3@gmail.com> wrote:

> I think that further exploration of AODVv2 and any AODV
> implementation problems would be useful topics for the MNET WG and that we
> should consider adding that to the Charter.

IMHO, there are/was no problems reported by any participant within any IETF
list or any IETF WG meeting regarding AODV (RFC3561) or any MANET
experimental RFC. Please refer me to the problems so we can discuss them
one by one on this WG list.

However, last MANET WG meeting there was input that implementing Multicast
has many problems for MANET, which the input was without details. So we
will need a report in this WG about what was those Multicast problems
especially for our RFC6621, to help progress.

Best Regards,

> On Mon, Dec 4, 2023 at 8:42 AM Adamson, Robert B CIV USN NRL (5592)
> Washington DC (USA) <brian.adamson=40nrl.navy.mil@dmarc.ietf.org> wrote:
>> As Justin Dean mentioned, our nrlsmf code can act as tun/tap user-space
>> forwarding engine (and works on Linux (including Android ... although newer
>> Android policies have locked out use of some the the netlink APIs and I
>> haven't tested that in a while), OSX/BSD, and even Windows with use of
>> WinTAP (or whatever it's called).  We have done some stuff with that using
>> our own forwarding tables or with the OS tables but not yet for AODV.  For
>> AODV some sort of extra packet caching could be useful or do something
>> similar with what we do with the Elastic Multicast implementation to flood
>> until the "on demand" route is established.  Related to that the "nrlsmf"
>> code has support for some hybrid policies that can be set related to
>> flooding/forwarding such as token bucket limited forwarding rate until a
>> route is established or flooding a small number (e.g, burst) of packets
>> initially upon a new flow until a route is established.  With a little
>> tweaking, these could be extended a little bit to support other caching
>> strategies if desired.
>> Also, with the code, I have _slowly_ been refactoring code to keep the
>> forwarding plane aspects of the the nrlsmf "engine" distinct and separate
>> from the control plane aspects with the idea in mind to eventually have the
>> forwarding plane code be used independently in a kernel module (or
>> elsewhere) with the various forwarding plane features we see needed for
>> these sorts of protocols including duplicate packet detection, control
>> plane updates like mentioned for AODV2 below, per-flow forwarding state,
>> etc.  It's been _slow_ since my time to work on it is quite limited these
>> days.  Meanwhile, we do get pretty good performance with it in user space,
>> and I know there's improvements that could be made.
>> If the kernel forwarding table is used, there are ways (not pretty) to
>> update by using a pcap socket to monitor packets and do that independently
>> of the actual forwarding.  Again, not pretty or efficient, but a work
>> around until such features are resident in the forwarding engine.  That's
>> one of the things I see needed, including for the Elastic Multicast
>> protocol operation, to have the forwarding plane notify the control plane,
>> at least periodically and/or on an event-driven basis (e.g., new flow
>> detected).  On Linux, I think that ideally would be through a netlink
>> interface and my thought on encapsulating a forwarding mechanism like what
>> "nrlsmf" provides into a kernel module would include that interface.  For
>> example, to support the "per flow" packet processing and such
>> notifications, I created a "Flow Description" data structure that's also
>> used as an index on a modified Patricia Trie prefix-based radix tree (with
>> field wildcarding support) to detect, identify, and classify packet flows
>> for such purposes.
>> Cheers,
>> Brian
>> On 12/4/23, 9:04 AM, "manet on behalf of Henning Rogge" <
>> manet-bounces@ietf.org <mailto:manet-bounces@ietf.org> on behalf of
>> hrogge@gmail.com <mailto:hrogge@gmail.com>> wrote:
>> Hi,
>> I was thinking about how to implement AODV2 on a TUN but hit an
>> interesting issue when reading through the "Interaction with the
>> Forwarding Plane" chapter of AODVv2...
>> Chapter 6.4:
>> "AODVv2 needs to update the record of when a route was last used to
>> forward a packet".
>> Does this mean AODV cannot use the kernel routing forwarding system
>> and is expected to do everything in user space? I ask because the
>> "routing cache" (and its statistics for each route) were removed from
>> Linux in version 3.6.
>> Henning Rogge
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org <mailto:manet@ietf.org>
>> https://www.ietf.org/mailman/listinfo/manet <
>> https://www.ietf.org/mailman/listinfo/manet>
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet