Re: [homenet] DNCP/HNCP Revisited

RayH <v6ops@globis.net> Fri, 20 September 2019 10:20 UTC

Return-Path: <v6ops@globis.net>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC5D120125 for <homenet@ietfa.amsl.com>; Fri, 20 Sep 2019 03:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.222
X-Spam-Level:
X-Spam-Status: No, score=-0.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, MISSING_MIMEOLE=1.899, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 qSABfHdp2sZy for <homenet@ietfa.amsl.com>; Fri, 20 Sep 2019 03:20:47 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9F712011D for <homenet@ietf.org>; Fri, 20 Sep 2019 03:20:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7279640195; Fri, 20 Sep 2019 12:20:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAklthIbeKEf; Fri, 20 Sep 2019 12:20:41 +0200 (CEST)
Received: from [192.168.1.14] (h9041.upc-h.chello.nl [62.194.9.41]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 12A3D400AD; Fri, 20 Sep 2019 12:20:41 +0200 (CEST)
Date: Fri, 20 Sep 2019 12:20:39 +0200
Message-ID: <be600313-ed7b-40d5-b44a-92b38f9ada8c@email.android.com>
X-Android-Message-ID: <be600313-ed7b-40d5-b44a-92b38f9ada8c@email.android.com>
In-Reply-To: <87woe3vqbj.wl-jch@irif.fr>
From: RayH <v6ops@globis.net>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: HOMENET <homenet@ietf.org>
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/2ndGPxQBXoXh9vx1b_WTToFUjWo>
Subject: Re: [homenet] DNCP/HNCP Revisited
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Sep 2019 10:20:49 -0000

Hi,

I've done some more investigation and the "problem" packet size growth looks to be the result of a single UDP reply packet containing multiple node state TLV's.

This reply is triggered by a query from a new node joining an existing network, where the new node requests node TLV updates for all of the existing routers in a single request packet.

It would seem to me that there needs to be some clarification for implementations to avoid excessive packet growth, and potentially exceeding the limits of UDP fragmentation, with unpredictable results.

1) DNCP allows an option of whether a network state TLV contains optional nested payload (HNCP) TLV's or not.

There is no TLV defined in DNCP to indicate whether optional data has been included or excluded, or whether the node TLV optional payload is simply empty.

If one or more (optional) node data TLV's are included nested in the network status TLV reply, the reply could grow unbounded.

Humbly suggest: In order to avoid excessive growth of network status TLV's, and to allow trickle to work effectively, the HNCP profile should specify that optional data SHOULD NOT be sent with a network status TLV reply.

Node status updates SHOULD be explicitly requested where necessary to obtain updates of optional data, separately from network status TLV updates.

2) The node requesting a node status TLV doesn't know in advance how big a reply packet will be generated.

DNCP states that nodes MUST reply to all node status TLV queries.

So requesting multiple node status TLV's in one packet could lead to an oversized UDP reply packet.

Humbly suggest: In order to avoid potential overflow of the size limits of UDP reply packets, an HNCP node SHOULD NOT request more than one node status TLV update per request packet.

Thoughts?


On 20 Sep 2019 01:06, Juliusz Chroboczek <jch@irif.fr> wrote:

> I notice in the current Openwrt code that the max UDP packet size is set at 9000 octets with the comment:

> /* Very arbitrary. On some implementations, I have seen some issues
>  * with 10+kb frames so we use this for now. It MUST be significantly
>  * more than 4k, due to how code is written at the moment. */
> #define HNCP_MAXIMUM_UNICAST_SIZE 9000

> With current code (without expanding the TLV data set), and my sample
> test routers, that sets a current maximum network size of approx. 12
> nodes.

I don't think that the limit applies to the total network size, it applies to
the maximum size of a single NODE-STATE TLV.  If memory serves, HNCP is
able to send each NODE-STATE in a separate datagram, so the network can
grow without bound; it's the amount of data published by a single node
that is limited to slightly less than 9kB.

However, I agree that this could prove problematic if you build a very
dense network (a single node with a lot of neighbours) or if you have
large numbers of external connections terminating at a single node.

-- Juliusz

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet