Parent request retries on router ID sequence timeout

[sarveshkumarv3]

Observing too many parent request attempts on router ID sequence timeout. Overall the procedure takes around additional 21s after network ID timeout (120s). Following up to clarify the intended behavior here.

The observed behavior (from the below log) is that

• Same partition attach has 6 attempts to all routers and REEDs
• Same partition attach retry has 6 attempts to all routers and REEDs
• This is followed by any partition attach which has 2 attempts to routers followed by 4 attempts to routers and REEDs

//Router ID sequence timeout detected here 

00:43:22.415 [D] Mle-----------: network id timeout = 120
00:43:22.415 [I] Mle-----------: Router ID Sequence timeout

// Same partition attach attempt here

00:43:22.416 [N] Mle-----------: Attach attempt 0, SamePartition
00:43:22.416 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:23.671 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:24.922 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:26.174 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:27.427 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:28.680 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:29.935 [I] Mle-----------: AttachState ParentReq -> Idle

// Same partition attach retried here

00:43:29.936 [N] Mle-----------: Attach attempt 0, SamePartitionRetry
00:43:29.936 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:31.191 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:32.442 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:33.697 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:34.952 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:36.203 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)

// Any partition attach 

00:43:37.453 [I] Mle-----------: AttachState ParentReq -> Idle
00:43:37.454 [N] Mle-----------: Attach attempt 0, AnyPartition
00:43:37.454 [I] Mle-----------: Send Parent Request to routers (ff02:0:0:0:0:0:0:2)
00:43:38.209 [I] Mle-----------: Send Parent Request to routers (ff02:0:0:0:0:0:0:2)
00:43:38.964 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:40.215 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:41.467 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:42.722 [I] Mle-----------: Send Parent Request to routers and REEDs (ff02:0:0:0:0:0:0:2)
00:43:43.974 [I] Mle-----------: AttachState ParentReq -> Idle
00:43:43.975 [N] Mle-----------: Role router -> leader

From the 1.3.1 spec text Section 4.5.1, the six attempts for AnyPartition attach makes sense. But for same partition attach, it is not clear that it should be tried to Routers and REEDS 6 times. As per section 5.16.1, it seems to me that same partition attach to a parent with new sequence ID should be attempted once and if it fails, it should either attempt same partition attach again once or any partition attach but not both (which is not clear) before forming its own partition?

[abtink]

Thanks @sarveshkumarv3.

I think it may be helpful to file a JIRA in Thread Technical Committee for it to be discussed and/or clarified in spec. (Section 5.16.1 does refer to section 4.5).

Changing this in the code (to have fewer attempts depending on the AttachMode being kSamePartition, or kAnyPartition or ...) should be relatively straight-forward, but would be good to make sure it is desirable (and useful) to do so.

I think te concern/desire is to reduce the time duration before device decides to become leader?

The idea of having more retries is to ensure if we move to new AttachMode we really validated that we could not attach using the previous mode (to avoid re-attaches and partition merged due to temporary disconnects and/or poor link issues). So we have balancing act here.

My immediate idea/thought on this is to have a total of 6 attempts in SamePartition mode (all to Routers and REEDs) and then go to AnyPartition mode (skip/remove the SamePartitionRetry mode fully).

[jwhui]

I think SPEC-1036 provides valuable context here. In particular, the following change:

Before Thread 1.3.0:

A Router MUST make two separate attempts to reconnect to its current Partition, or a higher priority one, in this manner.

Thread 1.3.0 and after:

A Router MUST make one attempt to reconnect to its current Partition, or a higher priority one, in this manner.

So it sounds like we missed this change in the Thread 1.3.0 Spec.

[jwhui]

Yes, I think so.

[abtink]

Submitted this PR related to this:

• [mle] simplify reattach on losing connectivity to leader #9479

[sarveshkumarv3]

Thanks @abtin and @jwhui.

Checking with you, as it is not very clear to me from the text that the first attempt to attach to same partition should also be 6 attempts (scan mask = Router and REEDs as opposed to scan mask = 2 attempts of Routers + 4 attempts of Routers and REEDs).

Removing the additional 1 attempt of same partition retry should reduce the attach time by (~6*1.25s = 7.5s).
But Isn't 12 attempts still too high (10 * 1.25 + 2 * .75 = 13.5seconds)?

[abtink]

Here is the text from one of the comment in the JIRA (which seems to align with what we have now):

The 5.16.1 text is now updated to define “one attempt” of the process described there - a Router will be looking for same Partition with 2+4, before switching on to looking for any Partition with 2+4 as defined by section 4.5.1.

This make sense to me (having 12 attempts). It is a balancing act: I understand in some cases (when there are few routers) it may be desirable to shorten the time and have device take on leader role more quickly. On the other hand, if the original leader comes back and/or multiple devices end up taking leader role we may create partitions which can take longer to mend.

[jwhui]

The following PR has been merged:

• [mle] simplify reattach on losing connectivity to leader #9479