Improve EID-to-RLOC Address Query behaviour when Rloc address has changed.

[franzney14]

Hello,

Setup
Two nodes communicating in a Thread network via unicast UDP.

• Node1 (Leader) Sending requests to Node2.
• Node2 (Child of Node1) Responding to Node1.

Constant high network traffic.
Node1 is periodically sending requests (~30ms) to Node2.

After a few seconds Node2 is requesting to upgrade to a router because the numbers
of active routers is below the ROUTER_UPGRADE_THRESHOLD.

The message exchange for the upgrade procedure:

1. Node2 is sending a Address Solicit Request (a/as).
2. Node1 is accepting by sending a Address Solicit Response.
3. Node1 is sending a Address Query (a/aq) to update EID-to-RLOC mapping table.
4. Node2 is responding with a Address Notification (a/an) containing the new RLOC address.

Problem Description

Issue 1:
I see no reason why Node1 needs to issue a new Address Query to obtain the new Node2 Rloc address.
The address solicit message request already contains all information needed to update the EID-to-RLOC table of Node1.

Address Queries are send multicast and causing high network traffic. Should be avoided if possible!
Of course this only works for the Leader. Other Routers in the network would still need the address query.

Issue 2:
Buffered Requests and even new requests from Node1 are still send to the old Node2 Rloc address until Node1 is triggering an Address query to obtain the new Node2 Rloc address.

This is causing high traffic load because unicast packages are repeated 16 times on 15.4 level if send to an invalid Rloc address.

Maybe this Address Query could be sent with a higher priority or the Rloc address of buffered messages could be updated.
Even deleting buffered messages with invalid or old Rloc's would be better than repeating 16 times.

Node2 could also send a Proactive Address Notification to Node1 as described in chapter 5.5.2.2 Thread specification.
This would avoid the multicast address query and is probably quicker.

---

Any ideas how to prevent or improve this behaviour?

Regards
Fränz

[jwhui]

I see no reason why Node1 needs to issue a new Address Query to obtain the new Node2 Rloc address.

The commit message of 34ecac8 provides a reason:

- On leader, when we successfully reply to an "Address Solicit"
  message and assign a new RLOC16 to a node, we clear all entries
  associated with old RLOC16. We do not change to new RLOC16 since we
  cannot be sure that child will successfully receive the Address
  Solicit" response.

Buffered Requests and even new requests from Node1 are still send to the old Node2 Rloc address until Node1 is triggering an Address query to obtain the new Node2 Rloc address.

This should not be the case since the Address Cache Entry is removed (see commit above).

[franzney14]

Thanks for the fast response.

Now it's clear why the Address Query is needed!

But I still periodically see that messages are sent to the old RLOC address.

Attached a wireshark screenshot with shows the problem.

You can see that a new Request (SeqNbr=0x4a8) is still send to the old RLOC address after a successful Solicit request upgrade.
I would expect that a new Address request is send if the address cache entry was removed?

[abtink]

Jonathan and I chatted about this.

This is a race situation and there seems to be no good answer/solution here.

The good thing is a child should start sending MLE Advertisements quickly upon becoming a router, sending the first MLE advertisement immediately as it processes the "Address Solicit" response. These MLE Advertisement messages will go to the head of its message queue (due to MLE traffic having higher priority over data messages).

When/if the former parent receives the MLE Advertisement, it will detect that its child is now acting as a router and update all address cache entries associated with the child to use its new RLOC16 (this behavior was added in #8987).

I also want to highlight the recent change in #9956 (with background discussion here #9416 (comment))

[franzney14]

Thanks for the details.

I can confirm that MLE Advertisements are sent very quickly when becoming a router. But we can not rely on this!
Receiving the MLE Advertisement seems to not stop the former parent to send the multicast address query.
Needs to be verified with the latest OT version.

Updating the Rloc source address of cached messages would probably prevent this issue. This seems to be the root cause of this race condition.
This race situation can also occur on large networks if a packet with the old rloc is already in the air and is delayed because of retransmissions or a longer route.

Network snooping could be disabled (only for this EID) for a few seconds after the address cache was deleted. This would avoid that the cache is updated by receiving a delayed package with the old rloc address.

[jwhui]

Network snooping could be disabled (only for this EID) for a few seconds after the address cache was deleted. This would avoid that the cache is updated by receiving a delayed package with the old rloc address.

The challenge is that we can't have it both ways. Disabling snooping would require sending a multicast Address Query to resolve the RLOC. Without an address cache entry, there's no way to send the response.

[abtink]

Submitted the following PR as a related enhancement:

• [mle] implement alternate RLOC16 usage during role transition #10006

Note that it requires radio platform support for new platform API.

[franzney14]

Inside the DALI Alliance we currently reviewing / retesting with the latest changes. I will provide feedback asap.
I have identified 3 commits that could be related:

• [mle] clear/update address cache entries on promotion of child to router
• [mle] retain direct child cache entries on Addr Solicit Response TX
• [mle] implement alternate RLOC16 usage during role transition