Re: [homenet] DNCP/HNCP Revisited

[RayH]

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

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