[homenet] DNCP/HNCP Revisited

["Ray Hunter (v6ops)" <[e-mail]>]

Hi,

I've been experimenting with Homenet before looking at enhancing HNCP 
for extended naming functionality (the current implementation only 
covers resolver configuration and not name server configuration).

During my testing I managed to break HNCP, so that it got stuck in a 
state where it didn't converge.

Looking at the specification in detail this shouldn't have been a 
surprise to me or anyone else due to the design choices that were made.



First observation: Running HNCP over L2TPv3 breaks HCNP because L2TPv3 
breaks UDP fragmentation (works as designed).

The L2TPv3 tunnel has a lower MTU than the local LAN, and does not 
report ICMP PTB, so HNCP packets in one direction get through, but 
replies get dropped.

Early drafts of HNCP stated that UDP fragmentation would not be broken 
in the Homenet for the foreseeable future. Well I managed to break that ;)

So this is a known situation.

Changing the MTU on the LAN interfaces of my routers to 1280 brought 
everything back to normal, as expected.

Question: If Homenets are moving to flat L2 meshes over foo, as some 
have said, will this impact HNCP?

The Linux kernel (in Openwrt) can/could easily support PMTUD.

But since the L2 tunnels don't report drops, it makes PMTUD potentially 
challenging for a simple protocol like HNCP.

Question: As a simple mitigation, is there any way of manually 
signalling to the kernel that ALL UDP packets on port 8231 should assume 
an PMTU of 1280 octets?

That wouldn't require any specification change and would allow HNCP to 
work reliably in the presence of tunnels and varying MTU's that don't 
match the local interface MTU.




Second Observation: HNCP packets grow quickly in size, which may become 
a concern for scaling.

Again, by design, DNCP is limited to TLV content of 64K (RFC7787 intro).

AFAICS that is 64K per DNCP system, not per node.

Question: Is that correct?

For my 4 node Homenet, HNCP reached 3140 octets, without any 
modifications or additions or long names.

Question: Does the amount of state scale linearly with the number of 
routers?

Question: Is this starting to become a concern?

The limitation for 64K seems to come from the following:

RFC7788
Request Network State TLV (Section 7.1.1): The receiver MUST reply
       with a Network State TLV (Section 7.2.2) and a Node State TLV
       (Section 7.2.3) for each node data used to calculate the network
       state hash.


In the Openwrt implementation, I observe that the requester is 
requesting the node state for all 4 devices in one packet.

I also observe that the reply from the peer contains the entire state of 
the entire Homenet in a single UDP packet (network TLV and node state 
TLV for all 4 routers + optional payload data).

Question: Is that as designed/intended? Is this where the 64K data limit 
comes from in RFC7787?

If this was a design goal to reduce chatiness, and improve convergence 
time, is it possible to implement this differently to reduce packet size 
and/or increase overall TLV data capacity?

Could the requester in step1 request the network status TLV, and the 
peer reply with just the network status TLV and the node TLV's, but 
without the underlying optional HNCP payload data TLV's.

Maybe include a new "more-HNCP-data-to-come" TLV to distinguish this 
from blank node data?

That would give enough information for both nodes to know exactly which 
payload data needed synchronising.

Then as step 2, the requester could individually request the Node TLV 
for each node one per packet, and the peer would reply with the Node TLV 
but this time including the optional data TLV's.

The receiver and peer would both know that HNCP hadn't converged whilst 
waiting for the additional data, and could mark it internally as being 
stale whilst waiting for the additional detailed update.

Question: What would break?

Question: What would need to be amended in the standard RFC? The 
more-HNCP-data-to-come TLV in RFC7788?

Question: Would this tweak increase the ±64K limit of TLV data from 
being per network to being 64K per node? [max UDP packet size for a 
single node TLV + associated payload data]

Question: Is this raw fragmentation by separating DNCP essentials from 
HNCP payload something that the WG would support?

regards,

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>