Configuration changes from Thread version 1.3 to now

[jtaySWE]

Out of curiosity what were the significant configuration changes made from the old thread version 1.3 to the current version now, (such as changing from OPENTHREAD_CONFIG_MAC_DEFAULT_MAX_FRAME_RETRIES_DIRECT=3 to 15), and what were the reasons?

[jwhui]

The change from 3 to 15 for this configuration actually occurred in March 2021 (commit 498818a79d) and was driven by the Thread 1.2.1 specification (specifically Thread 1.2.1-draft4).

• Reason: The Thread specification increased the requirement for macMaxFrameRetries to improve link reliability and ensure better delivery of messages in dense or noisy environments.

In general, default values are only changed when a new specification requires it or when extensive field experience shows that a different default provides better behavior across most topologies.

[jtaySWE]

Hi @jwhui I do have another question about the configuration variable of OPENTHREAD_CONFIG_MAC_DEFAULT_MAX_FRAME_RETRIES_DIRECT. On the thread client nodes, can it affect the way it transmits messages like sending a coap message to coap server? Does it also have an affect on causing channel interference if it does send more retries through the link, what happens if it goes too small or too big?

[jwhui]

Yes, OPENTHREAD_CONFIG_MAC_DEFAULT_MAX_FRAME_RETRIES_DIRECT (IEEE 802.15.4 macMaxFrameRetries) applies to all unicast MAC direct transmissions, including CoAP traffic:

• Effect on CoAP messages: When sending a unicast CoAP message, the MAC layer retries unacknowledged 802.15.4 frames up to 15 times hop-by-hop (in milliseconds). This protects Non-Confirmable (NON) messages that have no application-level retries, prevents multi-second Confirmable (CON) CoAP timeouts, and keeps fragmented 6LoWPAN packets from failing if a single fragment experiences transient RF loss. (Multicast CoAP uses MAC broadcast and is unaffected.)
• Channel interference: Max retries only take effect when ACKs are missing—on healthy links, 15 vs. 3 adds zero extra traffic. On noisy or dead links, more retries do use more airtime, though OpenThread mitigates congestion using CSMA-CA (CCA) and random exponential backoff between no-ACK retries (OPENTHREAD_CONFIG_MAC_ADD_DELAY_ON_NO_ACK_ERROR_BEFORE_RETRY).
• If set too small (e.g., 0–3): Short 2.4 GHz interference bursts (Wi-Fi/BLE) will easily drop packets, causing multi-second CoAP latency spikes, higher end-to-end multi-hop retransmission overhead, and premature parent/neighbor detachment due to elevated MAC TX error rates.
• If set too large (well above 15): When a neighbor genuinely goes offline, the MAC layer will spend too long retrying a dead link—causing head-of-line blocking in the TX queue, wasting airtime and battery, and delaying link-failure detection.