[mpl] remove mpl entry from forwarding queue if the address query matches the host or one of its children

[sarveshkumarv3]

Remove the additional forwarding of AddressQuery messages if the current host or one of the children responds with AddressNotify

[size-report]

Size Report of OpenThread

Merging #9999 into main(a5c17b7).

name	branch	text	data	bss	total
ot-cli-ftd	main	466856	760	66364	533980
	#9999	466968	760	66364	534092
	+/-	+112	0	0	+112
ot-ncp-ftd	main	436140	760	61576	498476
	#9999	436236	760	61576	498572
	+/-	+96	0	0	+96
libopenthread-ftd.a	main	235904	0	40310	276214
	#9999	236010	0	40310	276320
	+/-	+106	0	0	+106
libopenthread-cli-ftd.a	main	57406	0	8075	65481
	#9999	57406	0	8075	65481
	+/-	0	0	0	0
libopenthread-ncp-ftd.a	main	31857	0	5916	37773
	#9999	31857	0	5916	37773
	+/-	0	0	0	0
ot-cli-mtd	main	364712	760	51220	416692
	#9999	364712	760	51220	416692
	+/-	0	0	0	0
ot-ncp-mtd	main	347244	760	46448	394452
	#9999	347244	760	46448	394452
	+/-	0	0	0	0
libopenthread-mtd.a	main	158229	0	25182	183411
	#9999	158229	0	25182	183411
	+/-	0	0	0	0
libopenthread-cli-mtd.a	main	39787	0	8059	47846
	#9999	39787	0	8059	47846
	+/-	0	0	0	0
libopenthread-ncp-mtd.a	main	24737	0	5916	30653
	#9999	24737	0	5916	30653
	+/-	0	0	0	0
ot-cli-ftd-br	main	535728	768	131076	667572
	#9999	535824	768	131076	667668
	+/-	+96	0	0	+96
libopenthread-ftd-br.a	main	299357	5	104998	404360
	#9999	299463	5	104998	404466
	+/-	+106	0	0	+106
libopenthread-cli-ftd-br.a	main	71069	0	8099	79168
	#9999	71069	0	8099	79168
	+/-	0	0	0	0
ot-rcp	main	62248	564	20604	83416
	#9999	62248	564	20604	83416
	+/-	0	0	0	0
libopenthread-rcp.a	main	9542	0	5052	14594
	#9999	9542	0	5052	14594
	+/-	0	0	0	0
libopenthread-radio.a	main	18870	0	214	19084
	#9999	18870	0	214	19084
	+/-	0	0	0	0

[abtink]

The aMessage we get here is already gone through IPv6 and UDP layers and all those header are stripped/removed from it. It contains the UDP payload.

I see that you are accounting for this and compare byte in message accordingly from offset message.GetLength() - sizeof(Metadata) - len (practically checking if bytes at the end of message match bytes in aMessage).

I wonder if this is always safe/correct to do. Can we have an unintended match here?

If we could be sure that both message are TMF (using TMF port), I feel it may be safer then to compare the UDP payloads. Thoughts?

[sarveshkumarv3]

We are comparing around 30 bytes, for the entire TMF payload, do you think it can still have a risk of false match? I was trying to keep it generic and avoid any specific flags passed to the MPL module, but sure we can add that if you think it is unsafe.

The approach I was thinking of, is to pass a boolean to indicate it is a TMF message in the method RemoveMplEntry and then use than that to compare the port information in MPL module ( Mpl::RemoveMatchedMessage)to check if it matches TMF port. The challenge here is, we wouldn't have parsed the UDP header yet while adding the MPL message to the buffered set (in HandleExtensionHeaders-> Ip6::HandleOptions) and may need to parse it now, and do that again while HandleDatagram which becomes a bit messy?

[jwhui]

The optimization in this PR seems to only address a very specific scenario. In particular, any neighboring active routers will continue to forward the MPL message.

[sarveshkumarv3]

The optimization in this PR seems to only address a very specific scenario. In particular, any neighboring active routers will continue to forward the MPL message.

Sure @jwhui, the gains may not be much but can vary depending on topology right? In the best case, if there are 2 partitions fragments merged via single node, then we can avoid forwarding this message into one of the partition fragment? If there are N routers, we could avoid 2(N-1) messages?