Thanks for your response.
Juliusz Chroboczek wrote on 20/09/2019 12:40:
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.
The Network-State TLV only contains the network state hash, short
Node-State TLVs are separate top-level TLVs. An implementation may choose
to send them in the same packet, but they're independent TLVs and can be
sent in different packets.
A OK so you're saying this is already covered in (Section 4.4 of) 7787
Upon receipt of:
o Request Network State TLV (Section 7.1.1
<https://tools.ietf.org/html/rfc7787#section-7.1.1>): The receiver MUST reply
with a Network State TLV (Section 7.2.2
<https://tools.ietf.org/html/rfc7787#section-7.2.2>) and a Node State TLV
(Section 7.2.3 <https://tools.ietf.org/html/rfc7787#section-7.2.3>) for
each node data used to calculate the network
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.
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.
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.
In other words, the only constraint is that every single node state TLV
must be sent in its entirety within a single packet. As described in
a previous mail, this does bound the amount of data that a single node can
publish, but no bounds on the total size of the network.
So requesting multiple node status TLV's in one packet could lead to an
oversized UDP reply packet.
The replying node's behaviour has nothing to do with whether the requests
are aggregated in a single packet or not. The replying node processes
each request independently, whether it finds them in a single packet or in
multiple packets.
-- Juliusz
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
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,
and that multiple long UDP replies can be generated from a single query
packet (potential amplification).
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?
What behavior would we expect from the requester during this time?
Wait for all outstanding replies to arrive?
Re-transmit a node TLV request for missing / dropped replies?
Thanks!
--
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
