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

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

    On Tuesday, November 29, 2016 6:03 PM, Yasuyuki Tanaka <yasuyuki9.tanaka@toshiba.co.jp> wrote:

 Hi Qin,

Hmm, in your example, node A can resolve the inconsistency without
using the generation counter by sending CLEAR to node B after the
timeout occurs. Node A could use STATUS or STATUS+LIST before sending
CLEAR in order to confirm inconsistency if the schedule generation
inconsistency detection was disabled...

Best,
Yatch

On 2016/11/29 22:40, Qin Wang wrote:
> Hi Yasuyuki,
>
> I'm not sure I fully understand you.
>
> Let's assume node A wants to ADD cells with nodeB in 2-step
> transaction. After nodeA sends ADD Request to nodeB, the Timeout of
> nodeA is set. nodeB receives the ADD Request, adds the cells to its
> schedule and sends Response back to nodeA at same
> time. Unfortunately, nodeA does not get the Response before Timeout,
> then the schedules on two sides become inconsistent. In this case,
> only generation counter in the following message exchange can tell
> the difference. right?
>
> Thanks
> Qin

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch