When the parent receives a multicast message from SED, does it should forward this message back to SED?

[jinpeng1989]

Based on packet capture, when the parent device receives the multicast message from SED, the parent will forward this message back to SED. This action seems to have little significance. As the producer of the information, SED already possesses the content of this information. Does the specification define this detail? Does the parent need to forward the multicast message back to SED?

Frame 5803, SED (0x0401) send multicast message to Parent (0x0400).
Frame 5815, Parent (0x0400) forward the multicast message back to SED (0x0401).

[jwhui]

Based on the current implementation, this is expected. A Thread router will forward multicast packets as indirect transmissions to each SED that has subscribed to the IPv6 multicast address:

openthread/src/core/thread/mesh_forwarder_ftd.cpp

Line 87 in 01bce95

mIndirectSender.AddMessageForSleepyChild(message, child);

I think it makes sense to avoid sending it back to the SED that the router received the message from, but will have to see how this can be implemented with minimal overhead.

That said, do you have a real-world application that requires the SED to be both a producer and consumer of messages for the IPv6 multicast group? In many real-world cases, the producers and consumers of multicast packets are often different sets.

[jinpeng1989]

This behavior has two drawbacks. One is that it increases congestion, and the other is that it increases the power consumption of SED. The impact on power consumption might be greater, as the receiving time of the radio frequency transceiver has increased. For most Thread chips, the radio RX current and the TX current are of the same order of magnitude. For example, for a certain MCU, the RX current is 4.5 mA and the TX current @0 dBm is 5.2 mA.

If SED acts both as the producer and the consumer of a certain piece of information. The usual practice is to transfer this value within the internal application rather than through the communication interface.
If the multicast messages sent by the SED really need to be sent back to itself, I think it should occur at the network layer within the SED itself, rather than being sent back through the parent device.
For a non-sleeping Thread device, will the multicast messages generated by it be sent back to itself? Will the application of non-sleeping Thread device itself receive and handle/consume these multicast messages? I haven't conducted this experiment. It would be great if you could provide an answer.
If there is no send back for non-sleeping Thread device, then from the perspective of consistency, SED is also not necessary.

[jwhui]

Yes, as I mentioned in https://github.com/orgs/openthread/discussions/11862#discussioncomment-14222930, I understand the benefits of not reflecting the message back to SED. But it will require additional code.

Can you help answer the question above? Do you have a real-world application that requires the SED to be both a producer and consumer of the same IPv6 multicast group?

[jinpeng1989]

As far as I know, there isn't. I will double-check.
As I mentioned earlier, If SED acts both as the producer and the consumer of a certain piece of information. The usual practice is to transfer this value within the internal application rather than through the communication interface.

[jwhui]

Everything has a cost-benefit tradeoff. If there's no real benefit, then why bear the cost? If you really want the feature, please considering contributing a PR with implementation and associated tests for review.

[jinpeng1989]

Dear jwhui,

• For the question "Do you have a real-world application that requires the SED to be both a producer and consumer of the same IPv6 multicast group?", I discussed with the application experts. Yes, there will be such application scenarios, although they are quite rare. However, it does not rely on other devices in the network to send message back. Instead, this function was implemented within the application layer. As shown in the figure, the green path-3. Therefore, the path (the right part of path-1) which the Thread Router send message back can be removed.

• Regarding the implementation of this optimization, you are experts in OpenThread, so I still expect you to help with the implementation.

[jinpeng1989]

At present, we do not have the immediate capability to implement this optimization. We'll give it a try.

[martinzi]

Addressed in #12329