From nobody Thu Mar 24 04:56:36 2022 Return-Path: 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 E213D3A07BA for ; Thu, 24 Mar 2022 04:56:33 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHScRohxZXcA for ; Thu, 24 Mar 2022 04:56:28 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E933A07D4 for ; Thu, 24 Mar 2022 04:56:27 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id h1so5357151edj.1 for ; Thu, 24 Mar 2022 04:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oU0RU0gucfQgTz4jkICnswAfzyxm61eAxqVUcgT3MAM=; b=FRCapIspmeLefMHA4MRggXbMBESzRXE8CpzpB3OSGAqGOw19iriJvLdf7YMtcJSrIh v//d1VoFrNeQWcSfIJ/R6MhoeXPqJMpmJoaptGuP3QTGciALC76fScbUt7TBGqtC9xBv C7nqJO//7go2Ck2yNb09iykV+lqemDM8R71hsSYRKFxa9BMAVKw6N6t6DCq+LfyPMW+T 40e/pdB2BO5ACX1rQp1bLmwTo4410Sv0mnNzLCS5bxJifxAJR2htjyvYlMzdBDIqFhTQ Akuntjh4x6LS2hCQnKrAHtPhV2kuyGnlNa5henLmFnAFD9/uyxbyDBo/f9iRoQEk+zRT sa2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oU0RU0gucfQgTz4jkICnswAfzyxm61eAxqVUcgT3MAM=; b=zFLeWSiSKluno76lddbdvPPLaGyQ8uSGSyGrVBi30OoxXP7CvyW9bFex9Icwlpao5H CSc1UpLszC1F4HOVHXODvOOBcCqCOkL/JinUk9kXP3czVxol4oNb9tYnVBlOytK+TxXB KeWGaci+KTeOn3MXnoEMlt22Dc9Retd1Qqi99IDybzly4p8H3wdkG/b9JGwtFxRcdzf5 D0sUcFLlv6mVvLpLUDtlmIYZ6RkEMiBFypBe/15X4s7RBEjhp8yyZvHVDu7yZD9kmelE Ya5AbNtqHsEwHSw1jFQTU/INnK6hEM3J9Z+LtttqWib4w+Ns3isMqDEAZB2nor1riHXj 1H4Q== X-Gm-Message-State: AOAM533gEOSmuLW1Xfn03+0Hg1qU1OqwwbsUf5mHwPSBwDGP2TRm3B+E sCRu36/Ab0kDbZm4KDrjg9UGlEsTCnI= X-Google-Smtp-Source: ABdhPJwSd3tc/IM6bJznNoZ/iWq5pDo7MLjU0+gApDUvLjOGAEXJuGV8wGv4KrMYlzRreMLgJOpNiA== X-Received: by 2002:a50:c00a:0:b0:418:f10f:b27c with SMTP id r10-20020a50c00a000000b00418f10fb27cmr6193086edb.204.1648122985908; Thu, 24 Mar 2022 04:56:25 -0700 (PDT) Received: from smtpclient.apple (82-132-227-121.dab.02.net. [82.132.227.121]) by smtp.gmail.com with ESMTPSA id eg6-20020a056402288600b0041919c78082sm1336982edb.87.2022.03.24.04.56.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Mar 2022 04:56:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) From: Christopher Dearlove In-Reply-To: <3092CA13-2B57-43A3-A900-946B004D7915@nrl.navy.mil> Date: Thu, 24 Mar 2022 11:56:23 +0000 Cc: Henning Rogge , Philippe Jacquet , "manet@ietf.org IETF" Content-Transfer-Encoding: quoted-printable Message-Id: <7D630A3C-3F33-4D03-BA08-17C798A44331@gmail.com> References: <4E684853-DD75-4E36-B738-F9533E59F59A@gmail.com> <1903367784.7556571.1648065868312.JavaMail.zimbra@inria.fr> <41C9EDA9-DD51-4925-969A-8538D2B2800F@gmail.com> <3092CA13-2B57-43A3-A900-946B004D7915@nrl.navy.mil> To: "Adamson, Robert B CIV USN NRL (5522) Washington DC (USA)" X-Mailer: Apple Mail (2.3696.80.82.1.1) Archived-At: Subject: Re: [manet] SMF in Manet and MPR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2022 11:56:34 -0000 One of the best and worst things is that you have so many options - and = that you can change everything dynamically. Separately parameterised = interfaces, in particular message intervals. Link metrics (of different = sorts). Willingness. That the MPR selection process is only specified by = characteristics. That you can advertise more than the minimum needed. = And more. There=E2=80=99s an RFC or paper we never wrote (fragments of it exist = unpublished) discussing parts of this (which overlaps with motivation as = to why). > On 23 Mar 2022, at 21:29, Adamson, Robert B CIV USN NRL (5522) = Washington DC (USA) wrote: >=20 > I think there is some interesting things that could be done using the = MPR approach with some criteria. For example, you could use = source-based MPRs to build a shortest path tree that met certain = criteria (e.g., minimum throughput useful to the sender application or = some other set of QoS criteria). This isn't that different to what I = was describing with the experimental Elastic Multicast work that rides = on top of SMF (MPR-based, ECDS, even classic flooding) as it gets into = per-source (and even per flow) semantics ... >=20 > =EF=BB=BFOn 3/23/22, 3:21 PM, "manet on behalf of Christopher = Dearlove" wrote: >=20 > If there=E2=80=99s a shorter route, even if more hops, MPRs will = find it. So not suboptimal in that regard. >=20 > Flooding will try to travel over a shortest route. It might also = flood via other routes, because that=E2=80=99s the nature of flooding. >=20 > Flooding might be suboptimal in some regards, though not that one. = But of course in NHDP/OLSRv2 to want optimality is to put the cart = before the horse. We use the MPR flooding to find out remote = information. We couldn=E2=80=99t use it - even if we collected the right = metrics - to select MPRs as we already need them. >=20 >=20 >> On 23 Mar 2022, at 20:41, Henning Rogge wrote: >>=20 >> The problem is there might be a shorter 3-hop path to a single-hop >> neighbor than the direct path to it... which leads to a bad MPR >> choice. >>=20 >> So I think NHDP-based MPR selection is sub-optimal. >>=20 >> Henning Rogge >>=20 >> On Wed, Mar 23, 2022 at 9:04 PM Philippe Jacquet >> wrote: >>>=20 >>> If you choose the MPR with a given metric then the routing graph = will automatically show the shortest path wrt the metric as the = consequence of the 2 hop MPR coverage property. If such path does not = exist then the flooding cannot be achieved wrt the metric. >>>=20 >>> Philippe >>>=20 >>> ----- Mail original ----- >>> De: "Henning Rogge" >>> =C3=80: "Christopher Dearlove" >>> Cc: "manet@ietf.org IETF" >>> Envoy=C3=A9: Mardi 22 Mars 2022 09:37:47 >>> Objet: Re: [manet] SMF in Manet and MPR >>>=20 >>> My point about this issue is that as soon as the router knows that >>> there is a better way to a one-hop neighbor than the direct one, it >>> needs to stop using the link neighbor for flooding. But this is not >>> possible based on NHDP information, only with the help of the full >>> routing graph... which gives quite a few additional challenges = because >>> of the cyclic dependencies. >>>=20 >>> It's the same both for TC flooding and Multicast forwarding. Using a >>> VHF connection to flood them is a waste of precious (VHF) airtime if >>> we have a multihop UHF connection. It's just getting worse when we = add >>> userspace (multicast) traffic to the issue. >>>=20 >>> Henning Rogge >>>=20 >>> On Tue, Mar 22, 2022 at 9:23 AM Christopher Dearlove >>> wrote: >>>>=20 >>>> Flooding is done over the VHF interface because the whole point of = flooding is to reach everyone. And there might be some routers you can = only reach using the VHF interface. If you know that you can always = reach someone using only UHF flooding, and you consider that flooding = via VHF is a disaster, why is it one of your Manet interfaces? Or if you = want one hop transmission but not MPR selection why not set willingness = zero (never) on that interface? >>>>=20 >>>>> On 22 Mar 2022, at 06:31, Henning Rogge wrote: >>>>>=20 >>>>> On Mon, Mar 21, 2022 at 7:17 PM Christopher Dearlove >>>>> wrote: >>>>>> This depends on how you set up your link metrics. Flooding MPRs = have >>>>>> the option to use or not use link metrics. But if your interfaces = are different >>>>>> enough that you=E2=80=99d rather use multiple hops on a better = interface rather >>>>>> than fewer hops on a poorer interface, then you should be using = link metrics. >>>>>> If you aren=E2=80=99t, you will have problems. (They probably = show up even faster >>>>>> with routing.) >>>>>=20 >>>>> I don't think metrics can resolve my problem. The problem arises = from >>>>> calculating the MPRs just from the 2-hop neighborhood. >>>>>=20 >>>>> Let me sketch the problem.... imagine you have a Mesh with both = VHF >>>>> (slow long range) and UHR (fast short range) radios. >>>>>=20 >>>>> Now imagine your router R has a neighbor A on VHF, which is = two-hop >>>>> reachable on UHF... if A also has a neighbor even further away, A = will >>>>> ALWAYS be a MPR, because the neighbor of A is at least three hops = away >>>>> over UHV. >>>>>=20 >>>>> Unicast routes will still flow over the UHF network, but flooding = will >>>>> be done over VHF, which is a problem. >>>>>=20 >>>>>> And so the problem here is with that SMF predates link metrics, = and hasn=E2=80=99t >>>>>> been updated. It was even worse when I - and others - tried = multicasting >>>>>> by intercepting packets in the stack, wrapping them up as a new = OLSR (v1) >>>>>> message type and reinjecting into UDP (OLSR port), plus the = reverse at >>>>>> reception. Fun days. >>>>>=20 >>>>> The OLSR implementation from olsr.org has something like this = called >>>>> BMF... it was a disaster. ^^ >>>>>=20 >>>>> Henning Rogge >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20