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

[Qin Wang <[e-mail]>]

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 <[e-mail]> 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