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?
ThanksQin
On Thursday, November 24, 2016 9:27 AM, Yasuyuki Tanaka
<yasuyuki9.tan...@toshiba.co.jp> wrote:
Hi Qin,
Thank you for replying to my long email!!
I put the two cases you provided below, in which schedule generation
inconsistency could occur:
(1) failure in communication because of PHY problems like bed channel
condition, collision
(2) failure in processing because of MAC problems such as buffer
overflow.
These failures cause timeout at the 6P layer, don't they?
Why don't we consider a transaction ending with timeout as conceivably
inconsistent? If we would do that, we would not need to maintain the
generation counter; we would use wider bit space for SeqNum in a 6P
message. 6P could be simpler. It's up to a corresponding SF how to
deal with such a transaction.
Relying on timeout alone, we cannot tell if a concerned operation is
committed by a correspondent when the transaction ends with timeout. An
example is the case where a request is lost because of (1) or (2) in
2-step transaction. If the operation is not committed, the requester
takes wrongly the transaction as inconsistent. This case is what I
call false positive. It's not a big deal, I guess...
Best,
Yatch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
