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
<[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
