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
