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

[Yasuyuki Tanaka <[e-mail]>]

Hi Qin,

> 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?

Yes, that's right! I believe we are now on the same page about the
approach using timeout.

In this sense, ability to identify failure without inconsistency
occurred in the second part is the only advantage of the generation
counter, which is achieved by consuming four bits in every 6P packet
and keeping inter-transaction state for every neighbor. In my opinion,
this advantage is a little thing for the price to pay...

Best,
Yatch


On 2016/12/01 21:45, Qin Wang wrote:
> 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?
>
> Thanks
> Qin
>
>
> 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