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

[Qin Wang <[e-mail]>]

Hi Yasuyuki,
I think nodeA=>nodeB request process includes two parts, one is Tx from nodeA to nodeB, another part is for nodeB's MAC to process the Request message. As you mentioned, failure of the first part can be identified by mac-ack from nodeB, but not the second part. Right?
ThanksQin  

    On Wednesday, November 30, 2016 1:49 PM, Yasuyuki Tanaka <[e-mail]> wrote:
 

 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

_______________________________________________
6tisch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6tisch