Re: [manet] What was the Chameleon disaster?

Christopher Dearlove <christopher.dearlove@gmail.com> Sun, 15 October 2023 20:42 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 27246C15107F for <manet@ietfa.amsl.com>; Sun, 15 Oct 2023 13:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.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_NONE=-0.0001, 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: 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 hUFe8X_gIzTc for <manet@ietfa.amsl.com>; Sun, 15 Oct 2023 13:42:26 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 65F0FC151075 for <manet@ietf.org>; Sun, 15 Oct 2023 13:42:26 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-53b32dca0bfso7942072a12.0 for <manet@ietf.org>; Sun, 15 Oct 2023 13:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697402545; x=1698007345; darn=ietf.org; 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=e6xzQduCsI/TN4B7mgYNrVQIXEpJCI64m50SXb9+GS0=; b=H0vg/McN+7LZzVNnHReVIPn2JPrYzN5ZfdjiXA6tKHDL5hsOEeZu8uIeRB03QYQhIq k0fW2AWegEyMF4PFWQ6J3biiU131+6qw7NiynrnGhFnhKWiapQwXkyrTEBkEis3QtfUa dROklhNyy1Qz3eM7E4YwsDo3U5nK/RGip33uz8qC6r/AErHWkIhT0M7pGHTc8jwQzxWa NcfuEJP5PTGQAX3V1cqam32LrFfJl7fRi/ve8Mb/pkm4gYO0IBcGS4pTjSBYq44OlYNK diUfHCIBnLUpayJfmQQ/3GjtS76BSC5kD3eD9ONRj8Gq4q9TanDqOQZGWjBfasT9fZwa /6PQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697402545; x=1698007345; 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=e6xzQduCsI/TN4B7mgYNrVQIXEpJCI64m50SXb9+GS0=; b=sTrd3LLDALiMfniGuxRvRsNY9y9Q4SJM4nxJXFszBfCDqn+uSVioE+gGyyHL5F36yT I4i36Mecb7eRHuylJNcgzI0G3ON1wYDtTb4W4jTc9y4rz55IXnBM02k9TT+LdvD7M7NJ c+GnrTcaNIV+mC79BFiaUZBtE/QuX48z8himBYJGA/Q1k/EMXLkIIZr6r6FwYOffU0ya d12AtpflPrxeRoxVaJ9/j41GX2DIH2l0qlIn6jEtzwSCnBAcQnQyEulmUfpJro/6oOVc eWcnvfZfK76YmokUaj5/dgJAzqtyCyU77CerYSR+ux2UOawDFjbCDrw19Y3YEGSZTHur mS+w==
X-Gm-Message-State: AOJu0YyMMEmCrENNTPvnzkZECRNlybSial8XYOj+IqfoCRVl5HtbH2xF Uoj9i1g6elGdKDX15xGCHzs=
X-Google-Smtp-Source: AGHT+IFBuimswEEgFc5NJx9R9srdYShG7X4u3wEeniVBe8UJS0rqD7cxATnna7Xg+1T6XRAi9+Om8g==
X-Received: by 2002:a50:cc9d:0:b0:522:582c:f427 with SMTP id q29-20020a50cc9d000000b00522582cf427mr5308319edi.14.1697402544573; Sun, 15 Oct 2023 13:42:24 -0700 (PDT)
Received: from smtpclient.apple (82-132-227-243.dab.02.net. [82.132.227.243]) by smtp.gmail.com with ESMTPSA id b2-20020a50ccc2000000b0053e6e40cc1asm2601037edj.86.2023.10.15.13.42.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Oct 2023 13:42:23 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.100.2.1.4\))
From: Christopher Dearlove <christopher.dearlove@gmail.com>
In-Reply-To: <87h6mrpspd.wl-jch@irif.fr>
Date: Sun, 15 Oct 2023 21:42:11 +0100
Cc: Henning Rogge <hrogge@gmail.com>, James.A.Stevens@collins.com, manet@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE0A40FD-ED1C-45F5-9022-A55F1FFB0E6B@gmail.com>
References: <87il77py4w.wl-jch@irif.fr> <7F955961-A82E-41A2-AA4A-8BAC13C8C2E4@gmail.com> <87h6mrpspd.wl-jch@irif.fr>
To: Juliusz Chroboczek <jch@irif.fr>
X-Mailer: Apple Mail (2.3774.100.2.1.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/yYcgBwq3wqDflg7b-Gq20GcUupw>
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: Sun, 15 Oct 2023 20:42:30 -0000

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