[Roll] NCE vs DAO state saturation [was: roll-wg/draft-ietf-roll-enrollment-priority] Propose changes to reflect major points of our discussion (PR #14)]

Pascal Thubert <pascal.thubert@gmail.com> Fri, 11 February 2022 15:19 UTC

Return-Path: <pascal.thubert@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DFD3A09A4 for <roll@ietfa.amsl.com>; Fri, 11 Feb 2022 07:19:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 SONa9r3AQ7Fp for <roll@ietfa.amsl.com>; Fri, 11 Feb 2022 07:19:29 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 998D23A094E for <roll@ietf.org>; Fri, 11 Feb 2022 07:19:29 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id v12so15880588wrv.2 for <roll@ietf.org>; Fri, 11 Feb 2022 07:19:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:date:subject:message-id :references:to; bh=wZ+RuqXD9r0VqysROje3YBRqG9Pz05T2ct596xSTfUU=; b=kUsf+c9DZe+9+054MssqFrPVuZ9U8BEzGQ7tMuMhchOAcFPdExex18ji06zuBUGYAN QsMbLbKE0aixwt9momBb1SmIo7Sz13BDQfBzBcvCEA6KVIBmf/QaGTNq3Gbv49VKdLL8 5Mnvjzsa4lpbenYs5wLt7P0goTZHpOeemufoStUOPdwHKT8jhVUMuBuJkEVXdq0PTfco k6bbbFZM1TznihbZqdo/9fROcKi6pXGRM5ddvIhMOHLM0K1GnEpZKUc47yVmly44NF8h tCsFwD0jkAm6zWTOIOfcAHBa59KUtD03B1uINlqor/9FgQdJsyonRFbu0UUodtCh6MZ5 aAeA==
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:date :subject:message-id:references:to; bh=wZ+RuqXD9r0VqysROje3YBRqG9Pz05T2ct596xSTfUU=; b=Qpupz7KB+oUEm7Hcth7cBLN0vzECMsZe9+w5iCNobSeQQ0G9fkuBM23Awrc4yAYa7e s40HAa3gtWbgIqEQ0Mq1U5XqS8JhX4F8YM3LNpn9VWQmEqiiAKvI53UOGkl/dD7G4qfc 3a8pacS+yXbGpS4TafBLOKwUel1uI92sgTernvsuaR/fGWZ5ht6dg6DKZ/i57uOW5qji j39gyJuxOzwJ+LicbF6dU536I9hW9oU2colBrfAsgsSnotsKxCrEw1TWkiSy0f84LdAQ Z1PPqLYhAr3C2M6mpr40jdx/xlXU+CQ/zzbSSMLDADwkdvKQidl5CmV9pCIV9kFbAgQ/ KM7A==
X-Gm-Message-State: AOAM532FizLM8EchS9XGCK4fpATjK+ZAqTTy/joAXAgrFc98hr10x0wL OtTutv170rBeYkaiNy1l4F8+znl4N5E=
X-Google-Smtp-Source: ABdhPJx9Bqo28Dq1q25pqcUgEJYffMCG7BGYBl9yPNVv3qHHk7TQ6KJo8SIZDxKhLQdC4Sn+QsN1Vw==
X-Received: by 2002:a5d:61d0:: with SMTP id q16mr1771483wrv.615.1644592764428; Fri, 11 Feb 2022 07:19:24 -0800 (PST)
Received: from smtpclient.apple ([217.67.148.21]) by smtp.gmail.com with ESMTPSA id f2sm3610187wri.49.2022.02.11.07.19.23 for <roll@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Feb 2022 07:19:23 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-155CF975-F1EB-40FA-ADCD-5028402AF666"
Content-Transfer-Encoding: 7bit
From: Pascal Thubert <pascal.thubert@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 11 Feb 2022 16:19:22 +0100
Message-Id: <D5C694FF-5A06-4135-9344-0780955D0371@gmail.com>
References: <6C895AAD-89D5-4D59-8990-4491FE012B74@gmail.com>
To: ROLL WG <roll@ietf.org>
X-Mailer: iPhone Mail (19D50)
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/47eTeAbHK3XTk6Nll31HAk94Hds>
Subject: [Roll] NCE vs DAO state saturation [was: roll-wg/draft-ietf-roll-enrollment-priority] Propose changes to reflect major points of our discussion (PR #14)]
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Feb 2022 15:19:32 -0000

Replying from my phone gets me surprising destinations. Retry to the list:

> De: Pascal Thubert <pascal.thubert@gmail.com>
> Date: 11 février 2022 à 14:20:54 UTC+1
> À: roll-wg/draft-ietf-roll-enrollment-priority <noreply@github.com>
> Cc: roll-wg/draft-ietf-roll-enrollment-priority <draft-ietf-roll-enrollment-priority@noreply.github.com>, Push <push@noreply.github.com>
> Objet: NCE vs DAO state saturation [was: roll-wg/draft-ietf-roll-enrollment-priority] Propose changes to reflect major points of our discussion (PR #14)]
> 
> Dear all 
> 
> It appears reasonably easy and much needed to adapt rfc 8505 for sleeping nodes and NCE saturation, both of which should start at 6lo though we must impact rfc 9010 as well.
> 
> OTOH the saturation of the DAO state in storing mode is a hard problem. Basically a distributed asynchronous protocol that would overall balance a tree and even worse a dodag with possibly non equal loads. 
> 
> Worst case is that any router may be the single child of the root. Which means that that node should have as much state as the root itself. If that’s so then any node should be able to store the whole network.
> 
>  We designed storing mode with all that in mind and left it at that.
> 
> If there’s such a hard value for the size of the dodag then this draft is already sufficient for discouraging joins beyond the hard value.
> 
> The DAO projection work enables a hybrid mode where the amount of state in each node is supervised by a controller to optimize the value of the state that is installed, within the capabilities of each node, though the capabilities are for now know by an external mechanism. 
> 
> We can probably do more and I’d love to see research on that, but let us first complete the steps that we have taken, what do you think ?
> 
> Pascal
> 
>>> Le 10 févr. 2022 à 22:47, Konrad Iwanicki <notifications@github.com> a écrit :
>>> 
>> 
>> @konrad-iwanicki pushed 1 commit.
>> 
>> 8710275 editos and typos from Konrad Iwanicki
>> —
>> View it on GitHub or unsubscribe.
>> You are receiving this because you are subscribed to thi