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.tan...@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
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch