Re: [manet] SMF in Manet and MPR

Christopher Dearlove <christopher.dearlove@gmail.com> Tue, 22 March 2022 08:23 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 5BD8B3A0C77 for <manet@ietfa.amsl.com>; Tue, 22 Mar 2022 01:23:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, MIME_QP_LONG_LINE=0.001, 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 2lT8wkZOt5lX for <manet@ietfa.amsl.com>; Tue, 22 Mar 2022 01:23:45 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 441523A0C51 for <manet@ietf.org>; Tue, 22 Mar 2022 01:23:45 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id t11so23827298wrm.5 for <manet@ietf.org>; Tue, 22 Mar 2022 01:23:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=tuB+NBAluGUvvSVBVjQaokJR9m0U2blzBILEObg3pkw=; b=Q29cR1l7AyGPR7xdmXi2ny/bCZDipqOoHneOZ0443Cic/aswBw0A6upEHZC/1beDss mGhP3faLdSbt+mF9riocHZNz0cZjW/A0nKb+fYBAphLDPErvW42kMTV2NZUOJBSNkcU5 PHLHKaeKGTyq2ALbT9TMrPKtAQZyZ18cgZ/ReECgkRbXIxQ0cNdcsE8RONTCqWroNwy8 lJKNv7qd3WiJvT5hPyZPtxNezSbdzaIUBYWSSm6aVno4Vr6fooJ2sXtk35bn1CY1A6EK b9deOAzy5qMCaCVILPDlyajQ84p18dSmqNtrrBW8QU3r3jG5k/J4Ht+cdfQOeEfDyu3p 4z5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=tuB+NBAluGUvvSVBVjQaokJR9m0U2blzBILEObg3pkw=; b=lUd+1aMEn82McklLI2mSuvVnKln/gZ4YzRK++P2zM7VLuCSX2WBKxZAGHk+F6p9hL0 3CwUU3Npt/0RLQ3+HKSruf2HnIem+05UoZneP99X8gQvjIM5w4XyD8vcBdVd3qEw+dAg pCqnJ/atZCAlcd3nSXnNxOzbXLgRUcyorwCPKlHWrgcTyeyV9ezRtQ1vNrgUCF7mgkYP JK1munJAOVL2x3vTGxcYrVAXTizooCcAd4gTk8ygK1N4t/QlojS92+KM0XslXrmLlFwN Aq4gAKysZByn3lbyb46YFeBeZRbhlBv2NxMyOxAQTBoRi+oaGZKJoszBoBJcK0dZC5cn hmwg==
X-Gm-Message-State: AOAM530Ul4fcOOesniFjxaaEBDzAUBeTfTOmnLkGntNiYsYx+RxpfLx5 oS8oRZ9nl+2AvAiuETKGLVdh+Zh+q2A=
X-Google-Smtp-Source: ABdhPJylQM7JE6wLgHDVkDTohHB5o6KA0WzXF+AdncUTSCrQRiJV43YqxntMThifeZuVfQH8c15M5w==
X-Received: by 2002:a05:6000:15c2:b0:203:8348:8cbf with SMTP id y2-20020a05600015c200b0020383488cbfmr21578694wry.309.1647937422804; Tue, 22 Mar 2022 01:23:42 -0700 (PDT)
Received: from smtpclient.apple (82-132-227-37.dab.02.net. [82.132.227.37]) by smtp.gmail.com with ESMTPSA id n5-20020a05600c3b8500b00389dd6566f3sm1357509wms.19.2022.03.22.01.23.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Mar 2022 01:23:42 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Christopher Dearlove <christopher.dearlove@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 22 Mar 2022 08:23:41 +0000
Message-Id: <4E684853-DD75-4E36-B738-F9533E59F59A@gmail.com>
References: <CAGnRvuo36vQ8=ij+T2u-uyVNOAWx7Bkdrd9gLon20+dq_0XDiA@mail.gmail.com>
Cc: MANET IETF <manet@ietf.org>
In-Reply-To: <CAGnRvuo36vQ8=ij+T2u-uyVNOAWx7Bkdrd9gLon20+dq_0XDiA@mail.gmail.com>
To: Henning Rogge <hrogge@gmail.com>
X-Mailer: iPhone Mail (18F72)
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/Vh0eTNqECP_9r-cZ1IMNE7y7ki4>
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 <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, 22 Mar 2022 08:23:51 -0000

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?

> On 22 Mar 2022, at 06:31, Henning Rogge <hrogge@gmail.com> wrote:
> 
> On Mon, Mar 21, 2022 at 7:17 PM Christopher Dearlove
> <christopher.dearlove@gmail.com> 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’d 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’t, you will have problems. (They probably show up even faster
>> with routing.)
> 
> I don't think metrics can resolve my problem. The problem arises from
> calculating the MPRs just from the 2-hop neighborhood.
> 
> Let me sketch the problem.... imagine you have a Mesh with both VHF
> (slow long range) and UHR (fast short range) radios.
> 
> 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.
> 
> Unicast routes will still flow over the UHF network, but flooding will
> be done over VHF, which is a problem.
> 
>> And so the problem here is with that SMF predates link metrics, and hasn’t
>> 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.
> 
> The OLSR implementation from olsr.org has something like this called
> BMF... it was a disaster. ^^
> 
> Henning Rogge