Re: [homenet] DNCP/HNCP Revisited

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>