Re: [homenet] DNCP/HNCP Revisited

[Juliusz Chroboczek]

> AFAICS there's certainly enough room for me to experiment with patches to
> i) reduce MTU to avoid problems arising from L2 MTU mismatches and
> ii) to reduce the amount of fragments (at the expense of more UDP packets)
> without any tweaking of the standards.

In case you're interested, here's the code that decides whether to
aggregate or to ship out in shncpd:

  https://github.com/jech/shncpd/blob/master/send.c#L99

In short -- we try to limit our payload to 1412 bytes whenever possible,
within the constraints of not being able to fragment large TLVs.  (This
should depend on the outgoing interface's MTU, as in Babel, but I decided
I'm lazy and just hardwired the constant.)

> My reason for investigating ii) is to potentially reduce the impact of
> the loss of an individual frame on a lossy link (we would lose 1 node
> status TLV from 1 device rather than multiple TLV's related to multiple
> devices).

Recall, however, that 802.11 has absolutely horrific per-frame overhead.
Recall further that HNCP does flooding, so that if there are parallel
lossy and lossless links, packet loss on the lossy link doesn't matter as
long as the data gets correctly flooded over the lossless link.

In short, there is a non-trivial tradeoff here.

-- Juliusz

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

Re: [homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

Juliusz Chroboczek wrote on 20/09/2019 14:23:

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

I'm pretty sure that's not the case.  RFC 7787 Section 7.2.2.

A OK so you're saying this is already covered in (Section 4.4 of) 7787

[...]


   state hash.  The Node State TLVs SHOULD NOT contain the optional
   node data part to avoid redundant transmission of node data,
   unless explicitly specified in the DNCP profile.
So what I was suggesting was merely additional clarification of that.

Careful here.  There is no optional part in the *network*-state TLV - this
TLV's payload is just the network state hash.  The optional payload is for
the *node*-state TLVs.

I see now.

The network state TLV's and node state TLV's are completely separate 
TLV's (not nested in any way) that can be both generated as the result 
of one inbound request (request network state TLV), and they may be sent 
in separate UDP packets.

The replying node MUST reply to all node state queries.  However, it is up
to the replying node whether these replies are sent in a single packet or
split into multiple packets.

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

Yes, this was discussed back in July 2015.  Here's what I said back then:

 It should also say that a node MUST NOT send a datagram with a larger
 payload, and that it MUST silently drop any larger datagrams (optionally
 log to system management, etc.).  If this is not done, persistent state
 desynchronisation may occur.

This is what Markus replied:

 I am not sure I want to cripple use in non-crippled networks, just provide
 guaranteed base value which works everywhere and *RED ALERT* light should
 light up on crippledbox if it encounters this

Since nobody supported my position at the time, I had to agree to the
following:

   - Section 3 of RFC 778 says that "Each node MUST be able to receive (and
 potentially reassemble) UDP datagrams with a payload of at least
 4000 bytes."

   - there is no limit on the size of the packets that a node may send.


So if I understand you correctly, you're saying this is the problem of the
sender of the response to ensure UDP fragmentation doesn't break,

I'm not sure what you mean.  We certainly assume that the network obeys
RFCs 2460 and 4443.


and that multiple long UDP replies can be generated from a single query
packet (potential amplification).

Let's please discuss security at some other time, I'd like the current
discussion to come to a conclusion first.


If there's multiple UDP replies required for a single query, would you expect
sending of these individual packets to also be rate limited by trickle?

Let's please discuss congestion control at some other time, I'd like the
current discussion to come to a conclusion first.


What behavior would we expect from the requester during this time?

The requester parses each top-level TLV in turn, and acts upon it.

This is very illuminating for me, and removes a false assumption on my part.

Wait for all outstanding replies to arrive?

No.  The requester parses each top-level TLV and acts upon it as soon as
it arrives.


Re-transmit a node TLV request for missing / dropped replies?

How would the receiving node detect missing replies?

If some node-state TLVs are missing, then the receiving node's state might
not get updated correctly, which will cause the network hash to mismatch,
which will be detected when it receives a new network-state TLV
(trickle-driven, worst-case 17s).

-- Juliusz

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


Thanks very much for your patience and replies to my questions that have 
certainly filled gaps in my understanding of the protocol that I had 
from reading the standards and the code alone.


AFAICS there's certainly enough room for me to experiment with patches to
i) reduce MTU to avoid problems arising from L2 MTU mismatches and
ii) to reduce the amount of fragments (at the expense of more UDP packets)
without any tweaking of the standards.

My reason for investigating ii) is to potentially reduce the impact of 
the loss of an individual frame on a lossy link (we would lose 1 node 
status TLV from 1 device rather than multiple TLV's related to multiple 
devices).


--
regards,
RayH

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