Re: [homenet] DNCP/HNCP Revisited

[Mark Andrews <[e-mail]>]

> On 18 Sep 2019, at 5:36 pm, Ray Hunter (v6ops) <[e-mail]> wrote:
> 
> 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?

setsockopt(IPV6_USE_MIN_MTU=1); from RFC 3542 works provided the OS has implemented it.  It’s a really pity that POSIX hasn’t picked up RFC 3542 in the 16 years since it was published like they picked up RFC 3493.  This is a epic fail of SDOs.

> 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
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]