Re: [manet] What was the Chameleon disaster?

Henning Rogge <hrogge@gmail.com> Tue, 17 October 2023 07:03 UTC

Return-Path: <hrogge@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 ABEC1C14CEFC for <manet@ietfa.amsl.com>; Tue, 17 Oct 2023 00:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8RU44NShF05 for <manet@ietfa.amsl.com>; Tue, 17 Oct 2023 00:03:07 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 80136C14CE2F for <manet@ietf.org>; Tue, 17 Oct 2023 00:03:07 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-53db360294fso9412416a12.3 for <manet@ietf.org>; Tue, 17 Oct 2023 00:03:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697526186; x=1698130986; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FgnCEIt1itdmShago55n+vHzqxJK/gTlyIxmhwGfX5I=; b=KETvqjJeXkJ1ob7UQuSGVQos55TtGg/2sFqzEcwXrC8U5YwTZw9QtgwMiCEvOeG/1K Fejvx8KgwLU8EwLK79v/EhGkmdsUqo8zk8dU14tskaK83Up9QhcrD/si+e0fd0DHRVGq RzIAtyHcHDC83kACmg4soRcbF86VmQAZwe7w5pFP0/DS61JrRGRIN1hsGufwk5kz1NOf 7tWPhRFFctzDoR3wg3JlozNZwg6dd9Ei7iBYun1lrnXuUqcmshbTN5KGN2bYypi+VRfX nCjVKx7jb7OxXgqRO+ozOUIgMl1Tar0iHbrO+xX/Vx/7wfXp/t528pynQ8xKAUGkfClT MthQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697526186; x=1698130986; h=content-transfer-encoding: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=FgnCEIt1itdmShago55n+vHzqxJK/gTlyIxmhwGfX5I=; b=XG8yrXo8cREfvTzLCtwPa29nMd7GYeSl4TR9CTk+0l9mrIAPIKsge9Yw51Rg+ZE61X ZS/U1UHIdfU3kH/8Ern/0AmUE6DfA2c07NCEorVPPIj3wcnI1NwU8ZhzaqrU7nnlb9CC rqMaPWXEXsAN75AeR5PH0O1b3DWU47I4dkuw00AHSWYv/nrVA0hbK4UmoXRnWs2SrKub VMqy+NWLy4Vbs3yGucu8Xk2/vhnrFw7RAKaiZ7xU1B5bpZdGmHUvVhJxzQG0pbHUanJL RQjGWUe9DwwWbJz6ROdSj4emDOG6cFq52SC+PZVufHCAaFUk1KVJ8nb7FjyPxQWfq/hf s47A==
X-Gm-Message-State: AOJu0YyUUpFmG7COVvOws44+AvYi1TBJpEPtBjQAwrHUO2xcmFFsNCzT Hc65dpBa6vmHG9p4o8OtdaKonwp2yW51BAitbz4=
X-Google-Smtp-Source: AGHT+IH4v9P8gkPKG9dUYkpKGIHXo9aoNQSERdHMsXum2S2m9p2IDRwB/KWJR9ajQeHgDrD1u8d8/jOFLo8qvpM3nBY=
X-Received: by 2002:a17:907:1b05:b0:9c4:d19:4a64 with SMTP id mp5-20020a1709071b0500b009c40d194a64mr1235164ejc.25.1697526185546; Tue, 17 Oct 2023 00:03:05 -0700 (PDT)
MIME-Version: 1.0
References: <87il77py4w.wl-jch@irif.fr> <7F955961-A82E-41A2-AA4A-8BAC13C8C2E4@gmail.com> <87h6mrpspd.wl-jch@irif.fr> <BE0A40FD-ED1C-45F5-9022-A55F1FFB0E6B@gmail.com> <CAGnRvupWrCPc1-Q6Pi5vuAOi0ygStQGpoyKT_Y68gKcE7Ckk_w@mail.gmail.com> <EC7B3926-8B43-4022-B16B-8CDC1D7A2969@gmail.com>
In-Reply-To: <EC7B3926-8B43-4022-B16B-8CDC1D7A2969@gmail.com>
From: Henning Rogge <hrogge@gmail.com>
Date: Tue, 17 Oct 2023 09:02:39 +0200
Message-ID: <CAGnRvuobvUOK5SY5NFZZPNsf3qkFk6ZsX4WFwcMjS1m=Ev8Dzg@mail.gmail.com>
To: Christopher Dearlove <christopher.dearlove@gmail.com>
Cc: Juliusz Chroboczek <jch@irif.fr>, James.A.Stevens@collins.com, manet@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/E5f0RsrDqSaVTSGnPeTFctGoW-Q>
Subject: Re: [manet] What was the Chameleon disaster?
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, 17 Oct 2023 07:03:12 -0000

Yes,

I can also see more than a couple of points to go further, but even
the thing I sketched above is difficult at best... especially the
distributed algorithms that need to converge on global solutions
without constantly falling into a bad "local minima".

That's why I think designing a full hybrid protocol is a huge
effort... we might get an "easier" result by looking at how to improve
our current protocols (OLSRv2 and BABEL) to reduce their overhead.

Henning

On Mon, Oct 16, 2023 at 8:49 AM Christopher Dearlove
<christopher.dearlove@gmail.com> wrote:
>
> My view on a hybrid protocol took that further, but started as you say. One can view
> willingness to be an MPR (even separately for routing and flooding) as a policy as
> to what the router is prepared to do (easier to consider it binary as a starting point).
> Then, coupled with ideas of using a reactive RREQ/RREP mechanism as a supplement
> to the HELLO/TC mechanism, you can consider more general policy as to what a
> router is prepared to do. Maybe not prepared to send periodic messages, but prepared
> to forward RREQ/RREP messages, because administratively we have decided those
> are important. Or add a priority indication, thus making this, like willingness, not binary.
> Or many other possibilities, but that’s design.
>
> > On 16 Oct 2023, at 07:18, Henning Rogge <hrogge@gmail.com> wrote:
> >
> > For me the challenge in hybrid protocol is similar to the challenge of
> > a good OLSRv2 MPR algorithm. You want to have the ability for nodes to
> > completely (or nearly) sleep for some time, only doing work for
> > themselves, but you still need a well working total network. Which
> > means you need an algorithm that is good for both local and global
> > optimization, but don't fail when the amount of available information
> > drops (because some nodes don't provide global data anymore).
> >
> > In theory OLSRv2 can become a "semi-hybrid" protocol just by not using
> > certain nodes as MPRs for anyone, which means they only need to
> > participate in the HELLO protocol part (which is much cheaper than
> > forwarding TCs and data). But it's quite challenging to do so with a
> > distributed algorithm, especially when a change in topology might
> > force you to "re-awaken" certain nodes.
> >
> > Doing this "by configuration" is trivial, just set flooding- and
> > forwarding willingness of an OLSRv2 node to "never".
> >
> > Henning Rogge
> >
> > On Sun, Oct 15, 2023 at 10:42 PM Christopher Dearlove
> > <christopher.dearlove@gmail.com> wrote:
> >>
> >> Sorry, I don’t see what you mean by “announce a route to self” and how it helps. The hypothetical router that’s not joined the proactive network isn’t even known to exist by the other routers, because it has not joined their network. And that’s in the simplest of cases, where it is just one hop away from a proactive router and could - with some new signalling, just join enough to make it that router’s problem. But things can get more general than that.
> >>
> >> But it isn’t really important, as the key point is needing a use case. A hypothetical one - several in fact - is not trivial but not hard. But you need more than hypothetical to even know which of those would be worth pursuing. And I don’t see anyone offering that.
> >>
> >>> On 15 Oct 2023, at 20:54, Juliusz Chroboczek <jch@irif.fr> wrote:
> >>>
> >>>>>> which usually does, and should, mean real use cases
> >>>
> >>>>> Ok, I'll bite.
> >>>
> >>>>> What are the use cases for a hybrid protocol that are not satisfactorily
> >>>>> met by existing protocols?
> >>>
> >>>> Answering that question would be step one.
> >>>
> >>> Agreed.
> >>>
> >>>> In that hypothetical spirit, let’s suppose most users are happy with
> >>>> a proactive protocol. But there are a few who, due to need for
> >>>> covertness, or limited battery life or whatever don’t want to join
> >>>> in. But occasionally they might have a need to communicate. So are
> >>>> prepared to reactively establish a connection.
> >>>
> >>> At that point, they announce a host route to self, and point default at
> >>> a neighbour that announces a default route.
> >>>
> >>> https://www.rfc-editor.org/rfc/rfc8966.html#name-stub-implementations
> >>> https://github.com/jech/sbabeld
> >>>
> >>>> Or maybe they are prepared to accept such a connection.
> >>>
> >>> In this case, you need a protocol extension that requests a node to
> >>> announce a route to self.  It should not be too onerous to define, but I'd
> >>> like to convince myself there's an actual need.
> >>>
> >>> A use case for a true hybrid protocol would be somewhat more difficult to
> >>> construct, it would probably involve a node that doesn't need continuous
> >>> connectivity but at the same time can occasionally serve for transit.
> >>>
> >>> We, at Babel Towers, are of course always interested to hear about novel
> >>> use-cases for routing protocols.
> >>>
> >>> -- Juliusz
> >>
>