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