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

[Xavi Vilajosana Guillen <[e-mail]>]

HI Yatch,

thanks for your comments. Could you please summarize how the timeout will
work in the 2 and 3 step transactions:

I see it in this way:
2-step
A sends to B an ADD, if A packet is lost, B will never realize and A will
timeout. Idem if B response fails ( A timeouts)

3-step
A sends to B an ADD. If A packet is lost, B never realizes and A timeouts.
If B receives the packet but Response fails. A timeouts as before and B
timeouts for not receiving the confirmation. If the confirmation is lost B
timeouts and A should cancel or timeout because it does not receive ACK at
the MAC layer.

Is this your suggestion?

What if A resets? how you now at B that A has reset? do this require a
STATUS call from A to B when it join the network again?

thanks!
X



2016-12-01 22:34 GMT+01:00 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
>>
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>



-- 
Dr. Xavier Vilajosana Guillén­
Research Professor
Wireless Networks Research Group
Internet Interdisciplinary Institute (IN3)
Universitat Oberta de Catalunya­

[phone]| [e-mail]­ | Skype­: xvilajosana
http://xvilajosana.org
http://wine.rdi.uoc.edu/

Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 5. Edifici B3
08860 Castelldefels (Barcelona)



­