Re: [manet] What was the Chameleon disaster?

Henning Rogge <> Mon, 16 October 2023 06:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1BD1C14CE3B for <>; Sun, 15 Oct 2023 23:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Status: No, score=-7.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_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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b_rFec8jMpT7 for <>; Sun, 15 Oct 2023 23:18:41 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 5A2ACC14CE52 for <>; Sun, 15 Oct 2023 23:18:41 -0700 (PDT)
Received: by with SMTP id 4fb4d7f45d1cf-53d9f001b35so7037607a12.2 for <>; Sun, 15 Oct 2023 23:18:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1697437120; x=1698041920;; 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=e2SR96o/WPGRvyKwo6MZi66Ynb6LAxkjLUpaI8WHhr4=; b=nhgFZRlCStCs+KBgxKffjf+lvo4HHL+cTQ/DFw/5ERTkRkoCjTZxIl6sNDJ3QxTTNU OLjmlzg46mSwPhM4H1vBu229QwVTDsrxzBHlTSug2Br6IY/7zlNo9qM6qQF/J9e+vchK GwUKcIlnj4/KyFh8pwUkFdC/1YcGBOF9+G8rvveTaZflU7QCLGA1934Y3HZmIEb2efPe /c6EAmOhvc0LMm7jAxo/x7mNxlxpAVQg6sdv/T8+22afPOAR7pL0ibJgzsOQUqhvzqtY LQXudZNNvO+VddNZC6M0TyQFqF4CBAVlNlnPpR4jFG0b9tY4nh87XdgiUNupLdcHcfqS TH+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1697437120; x=1698041920; 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=e2SR96o/WPGRvyKwo6MZi66Ynb6LAxkjLUpaI8WHhr4=; b=MJ34+Y1X2bNsD1Eif4/g7zr1AcsyuSFm4HytP390quB8oAXS0RRXL1iayIhUNbgm/q tecHoAExB3Ppo/dSHkrGOPD+/HKI9rPuKRlVyxdYwy1+idaL+Pfo7QX8OL38hwrRwcqM haXQEQKikuJrhNeh19VMhq0G9LTqSauAC2miN3Pa5JnMdDxwwLLKzkawQAlMKBScz9wF b7EwgJkgm0Zne4bQgcLFXjMkSKBqbKqNfU0kyoCqeDXNXXTHrHkMGylLRC+QYdPGY33b dU822NZbJ5LM5C/MDP1t0j4IUeNZeogoOZokDc0TaLrDMyAlgOBQflosbI65iP5r84Dr H5kA==
X-Gm-Message-State: AOJu0YyLIUxItRFzyDlaQxE9SXdwhN7AO8c0kLjjnaE7XmcmwIyRPF4t haaErYkjG9dX8NrooPokEJRMsc5lzK+YLXWdLGI=
X-Google-Smtp-Source: AGHT+IHj+wUZnKZAttTLFumxwdDSecSU+hePtol5gUjRMTV4AdZDBCROjraQzNRlaT/c2X4bnwlAjWbeQuxavaB+SNo=
X-Received: by 2002:a17:907:94d2:b0:9be:e6d4:5751 with SMTP id dn18-20020a17090794d200b009bee6d45751mr5325318ejc.55.1697437119323; Sun, 15 Oct 2023 23:18:39 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Henning Rogge <>
Date: Mon, 16 Oct 2023 08:18:13 +0200
Message-ID: <>
To: Christopher Dearlove <>
Cc: Juliusz Chroboczek <>,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [manet] What was the Chameleon disaster?
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Oct 2023 06:18:45 -0000

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
<> 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 <> 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.
> >
> >
> >
> >
> >> 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