Relay behaviour of mesh when buffer is full

[Phil Young]

I'm trying to understand the limitations and configuration options for the mesh stack, in particular what happens when the mesh becomes busy.

From studying the code it appears that there may be an issue when receiving messages that need to be relayed if they cannot be queued for relaying immediately.

If I understand the code correctly messages for local use are checked against the replay cache which has one entry for each src address.so the replay cache needs to be dimensioned according to the number of src addresses that the node may be receiving from.

Messages to be relayed are not checked in the replay cache but are checked in the network message cache which seems to be set at 32 entries, if not found in the network message cache they are queued for relaying by calling packet_relay from network_packet_in, this attempts to queue them for relaying but may fail if there are insufficient resources, however this does not return any status to indicate failure.

regardless of whether the message was successfully queued for relaying the message is then added to the network message cache.

The implications of this appear to be that if a message cannot be queued for relaying immediately then it will never be relayed since subsequent reception of the message will cause a hit in the network message cache.

Have I misunderstood something.

What I am actually trying to establish is 3 things:

1: What happens when a node gets busy and cannot allocate a Tx buffer, does it drop Tx packets based on age, or simply not accept any new packet for transmission until one of the currently queued Tx packets has completed all schedules re-transmissions,

2: Is the total number of Tx packets shared between the originator and relay roles, or do they have independent limits?.

3: Is there any implementation of the guidelines for limiting the rate at which a node can originate packets, the BT Mesh specification says that the maximum rate of packets originated by a node should not exceed 24 packets per second, and that no node should originate more than 100 packets over a sliding 10 second window, I can't seem to find anything in the code for this?.

[Omkar Kulkarni]

Hi,

Your observation is correct, mesh stack will add network PDU to network cache even if it fails to relay. This is something that could be improved in the mesh stack.

About other points:

1. Tx path simply won't accept any new packets until there is sufficient space available in the buffer. It will not drop already queued packets. 

2. Packet buffers for originator and relay roles are different. Their sizes can be controlled by these settings: `CORE_TX_QUEUE_BUFFER_SIZE_ORIGINATOR`,  `CORE_TX_QUEUE_BUFFER_SIZE_RELAY`.

3. Mesh stack will not check for the number of packets getting originated. The recommendation specified in the mesh specification is not an enforced shall statement. It is mainly directed towards end application developers and network administrators to not configure (many) nodes in their network such that they will generate a lot of traffic. However, in a certain application specific scenario, there could a reasonable requirement to do so for a short period of time without harming a network at large (for example, health model publishing faults at a higher cadence, while other models on other elements on the same node are also publishing their own messages, leading to a higher number of messages being published by a node until the fault is resolved.) Applying a stack level constraint will kill the possibility of momentary higher traffic for valid reasons.