CoAP message size and likelihood of retransmission

[jtaySWE]

If for openthread the IEEE mac frame size used is 127 bytes, what's the recommended coap message size to reduce the likelihood of retransmission in a lossy network? For instance i use aiocoap for my coap server. When i transmit an observe message of 119 bytes to esp-idf device, where i have about 35-40 esp-idf devices as client connecting to the coap server, it can make it but sometimes it would also retransmit even possibly where it could take 40 seconds to reach to the client.

[jwhui]

The behavior you're seeing—long latencies and frequent retransmissions—is a classic symptom of 6LoWPAN fragmentation in a lossy or congested network.

Why 119 bytes is problematic

While the IEEE 802.15.4 physical frame size is 127 bytes, the actual space available for your data is much smaller due to overhead at every layer:

• MAC Layer Header & FCS: ~13–23 bytes.
• MAC Security (AES-CCM-32): ~9–14 bytes (Auxiliary Security Header + 4-byte MIC).
• 6LoWPAN IPHC Header: ~2–15 bytes (Compressed IPv6 header).
• UDP Header (Compressed): ~1–6 bytes.
• CoAP Header: 4 bytes + Token (0–8 bytes) + Options.

In a typical Thread configuration (short addresses, security enabled), you generally have roughly 75–90 bytes available for the CoAP payload before the packet must be fragmented. A 119-byte CoAP message will almost certainly be split into two 6LoWPAN fragments.

The Impact of Fragmentation

Fragmentation is particularly "expensive" in lossy environments for several reasons:

1. Multiplicative Loss: Standard 6LoWPAN does not retransmit individual fragments. If any fragment of a packet is lost, the entire IPv6 packet is discarded by the receiver. This exponentially increases the probability of a CoAP retransmission being triggered.
2. Congestion & Collisions: With 35–40 devices, the additional frames generated by fragmentation increase the likelihood of radio collisions (CCA failures), especially if multiple devices are receiving "Observe" notifications simultaneously.
3. CoAP Backoff: The 40-second delay you observed suggests that several CoAP retransmissions are failing. CoAP uses a binary exponential backoff; if the first few attempts fail due to fragment loss, the timeout quickly grows to tens of seconds.

By keeping your messages small enough to avoid fragmentation, you should see a significant improvement in both latency and success rate.

[jtaySWE]

@jwhui should i also be concerned about how fast the IEEE mac recovers from fragmentation? I don't know if it has an affect on trying to transmit other coap messages from coap server that would otherwise be small enough to fit inside the mac frame size (Like will it cause delay or fill up queue)

[jwhui]

Neither IEEE 802.15.4 MAC nor 6LoWPAN implement fragment recovery. If a fragment is lost, the datagram is lost, and the upper layer must retransmit the message.

As mentioned above, sending fragmented messages can more quickly lead to congestion issues, largely due to the fact that more application data is being sent.