Re: [homenet] DNCP/HNCP Revisited

[Juliusz Chroboczek]

>>> 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.

>> 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.

> 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

Re: [homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

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 
): 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.  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

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

Re: [homenet] DNCP/HNCP Revisited

[Juliusz Chroboczek]

> 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.

> 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

Re: [homenet] DNCP/HNCP Revisited

[RayH]

Hi,I've done some more investigation and the "problem" packet size growth looks to be the result of a single UDP reply packet containing multiple node state TLV's.This reply is triggered by a query from a new node joining an existing network, where the new node requests node TLV updates for all of the existing routers in a single request packet.It would seem to me that there needs to be some clarification for implementations to avoid excessive packet growth, and potentially exceeding the limits of UDP fragmentation, with unpredictable results.1) DNCP allows an option of whether a network state TLV contains optional nested payload (HNCP) TLV's or not.There is no TLV defined in DNCP to indicate whether optional data has been included or excluded, or whether the node TLV optional payload is simply empty.If one or more (optional) node data TLV's are included nested in the network status TLV reply, the reply could grow unbounded.Humbly suggest: In order to avoid excessive growth of network status TLV's, and to allow trickle to work effectively, the HNCP profile should specify that optional data SHOULD NOT be sent with a network status TLV reply.Node status updates SHOULD be explicitly requested where necessary to obtain updates of optional data, separately from network status TLV updates.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.So requesting multiple node status TLV's in one packet could lead to an oversized UDP reply packet.Humbly suggest: In order to avoid potential overflow of the size limits of UDP reply packets, an HNCP node SHOULD NOT request more than one node status TLV update per request packet.Thoughts?On 20 Sep 2019 01:06, Juliusz Chroboczek  wrote:> I notice in the current Openwrt code that the max UDP packet size is set at 9000 octets with the comment:



> /* Very arbitrary. On some implementations, I have seen some issues

>  * with 10+kb frames so we use this for now. It MUST be significantly

>  * more than 4k, due to how code is written at the moment. */

> #define HNCP_MAXIMUM_UNICAST_SIZE 9000



> With current code (without expanding the TLV data set), and my sample

> test routers, that sets a current maximum network size of approx. 12

> nodes.



I don't think that the limit applies to the total network size, it applies to

the maximum size of a single NODE-STATE TLV.  If memory serves, HNCP is

able to send each NODE-STATE in a separate datagram, so the network can

grow without bound; it's the amount of data published by a single node

that is limited to slightly less than 9kB.



However, I agree that this could prove problematic if you build a very

dense network (a single node with a lot of neighbours) or if you have

large numbers of external connections terminating at a single node.



-- Juliusz



___

homenet mailing list

homenet@ietf.org

https://www.ietf.org/mailman/listinfo/homenet


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