Re: [manet] What was the Chameleon disaster?

Christopher Dearlove <> Mon, 16 October 2023 06:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A87CBC14CE5F for <>; Sun, 15 Oct 2023 23:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Status: No, score=-7.106 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_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 dP4BTn175ORl for <>; Sun, 15 Oct 2023 23:49:21 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::634]) (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 E33A8C14F73E for <>; Sun, 15 Oct 2023 23:49:21 -0700 (PDT)
Received: by with SMTP id a640c23a62f3a-9c41e95efcbso84619866b.3 for <>; Sun, 15 Oct 2023 23:49:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1697438960; x=1698043760;; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Y0Q3eIiO2qbat2xITByyaL4yaqPb0ypgkFfNqd27ots=; b=lJTEmcOCSAwukeyOp6hiICdGVbwBpfCGNBVl8+rYw5DNQ72XoXqpYzbMFFJzCWoEQ8 lyoU5p8HIoL+/6IwROOBHJqNLC7VapS2UmlglWoi8xe6FpYHGOXCWubSM0BlXb3FOGW7 eTCDjQph/sqZ9wDUeIfU8DQRRNmVmzV6a7eBsJO9CFfq3pP0BsBjX9akFJbvmDchOkDE DWvAA1EliWF4PK/UYgebL/NIB9m376F0F97Ej3n9kERYSaeobv41+iviwpCRgMkXF9Hk kBKdjBWBEhQaa+Ycddc4+rRv3B9fwqa474+xQca5iS2jw+PlBfETRRHlFI2j4oPIslwF lraQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1697438960; x=1698043760; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Y0Q3eIiO2qbat2xITByyaL4yaqPb0ypgkFfNqd27ots=; b=wyXefp2ZzA5/iLdjkf7Q7Um5E0DlCUC4jfkaBNQwrMJmnNgHGejh6unsrak/OE2epN 51dA/lGmT2HqezK4W+HZlnaZB6cEL1isfadYNz1MHMNsxx1NWpCWU6CywoM1umKaV4p2 6mkhEtyel+KHD1M+aIgVredG6uAuVNAR2nTVe5TykcRGmv1rX5Mi+DC4cHLteKD6/5xP pznzKVFO8EGVtcURM+AkGA5fo20w0I43IEwydlwPfqHl4bs5AXnAdLWXVpJFcijlEAj8 NfZiCc/vv0bBfXZerSTbkaGB4hnCt9kgnnpd4/fu5dBZ4P6eAtoeTrgGm9QM4Jb16cod T7/g==
X-Gm-Message-State: AOJu0Yzbume2e6Eh8eZtgrDzrmUNyFuV6eArZpwCvDti8G7JecanY3cz ajrqhWbTdyW4kj/KXEj1Qo0=
X-Google-Smtp-Source: AGHT+IEvMKRz3Sc8NgH6JmMclFqL5K+qG+znOhFCSgSt7qJ7haes3TtZKXwEm79aKcb+CuF65uDdZw==
X-Received: by 2002:a17:907:1c23:b0:9bf:32c8:3106 with SMTP id nc35-20020a1709071c2300b009bf32c83106mr4618745ejc.2.1697438959956; Sun, 15 Oct 2023 23:49:19 -0700 (PDT)
Received: from ( []) by with ESMTPSA id hy1-20020a1709068a6100b0099bc08862b6sm3479695ejc.171.2023. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Oct 2023 23:49:19 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.\))
From: Christopher Dearlove <>
In-Reply-To: <>
Date: Mon, 16 Oct 2023 07:49:07 +0100
Cc: Juliusz Chroboczek <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Henning Rogge <>
X-Mailer: Apple Mail (2.3774.
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:49:25 -0000

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