Re: [6tisch] Handling Inconsistent Allocation in 6P

[Yasuyuki Tanaka <[e-mail]>]

Thanks, Qin.

> (1) Timeout in nodeA can be triggered either by failure in
> nodeA=>nodeB request process and by failure in nodeB=>nodeA response
> process (i.e the process in above example). nodeA cannot tell exact
> reason for a event of Timeout by itself. In another word, nodeA
> cannot tell there is a inconsistency between its schedule and
> nodeB's schedule just based on Timeout. Right?

That is right; failure in the nodeA=>nodeB case is what I called
"false positive." But, nodeA could lower the possibility of false
positive by using MAC-layer ACK, implementation efforts. If nodeA
doesn't receive a MAC-layer ACK to its request frame, nodeA can
consider the transaction as having failed without inconsistency.

> (2) sending CLEAR, or STATUS, or LIST usually happens after a
> inconsistency is found, and the function of generation counter is
> exactly to find out the inconsistency. Make sense?

I'd say the generation counter is not the only way to detect
inconsistency. STATUS/LIST could detect it as well, although
STATUS/LIST always fails with RC_ERR_GEN in a case of inconsistency
according to the latest draft.

The generation counter can find inconsistency as you mentioned, but it
has disadvantages:

- It needs 6P to keep per-neighbor states (ignore SeqNum for now) even
   when there is no ongoing transaction.

- It cannot detect inconsistency until a subsequent transaction; it
   may take a long time.

The reactive approach using timeout doesn't have such disadvantages;
furthermore, it's simpler than the the schedule generation management,
in my opinion.

I still cannot see why the generation management at 6P is really needed...

Best,
Yatch

On 2016/11/30 17:39, Qin Wang wrote:
> Hi Yasuyuki,
>
> (1) Timeout in nodeA can be triggered either by failure in nodeA=>nodeB request process and by failure in nodeB=>nodeA response process (i.e the process in above example). nodeA cannot tell exact reason for a event of Timeout by itself. In another word, nodeA cannot tell there is a inconsistency between its schedule and nodeB's schedule just based on Timeout. Right?
>
> (2) sending CLEAR, or STATUS, or LIST usually happens after a inconsistency is found, and the function of generation counter is exactly to find out the inconsistency. Make sense?
>
> Thanks
> Qin