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

[Yasuyuki Tanaka <[e-mail]>]

Hi Xavi,

Let me respond to the following first:

> What if A resets? how you now at B that A has reset? do this require
> a STATUS call from A to B when it join the network again?

That is one of options. Basically, it's up to an SF employed between
them. Here are other options in my mind:

   (1) A sends a Clear Request to B before the first transaction for
       Add or Delete operation since its reboot.
       # This is what SF0 of draft-02 does.

   (2) B notices that nothing has been received over scheduled cells
       with A or transmission to A over them is always fails.

     - Then, B sends a Clear Request to A. Or,

     - B tries to relocate such cells. Relocation fails because A
       doesn't have the cells to relocate (a proper return code is yet
       to be defined); then B sends a Clear Request to A.

Since these are independent of the generation counter, they could
happen even if the schedule generation management is used.

> Could you please summarize how the timeout will work in the 2 and 3
> step transactions: (snip) If the confirmation is lost B timeouts and
> A should cancel or timeout because it does not receive ACK at the
> MAC layer.

Sure, but I'd rather ignore ACK at the MAC layer here since it's a
message at a different protocol layer from 6P.

I drew some pictures so that we can see easily when and how timeout
occurs. Timeout event is supposed to be communicated to a
correspondent SF which decides how to deal with it.

[2-step transaction]

  (2-step.1) Request is lost: A gets Timeout

                 A            B
   Send Add Req. |            |
   + Start Timer |->x Add Req.|
                 |            |
                 |            |
         Timeout |            |

  (2-step.2) Response is lost: A gets Timeout

                 A            B
   Send Add Req. |            |
   + Start Timer |----------->| Recv Add Req.
                 |            |
                 |            |
                 |    Res. x<-| Send Res.
         Timeout |            |

  (2-step.3) Everything is fine: no timeout

                 A            B
   Send Add Req.	|            |
   + Start Timer |----------->| Recv Add Req.
                 |            |
                 |            |
   Recv Res.     |<-----------| Send Res.
   + Stop Timer  |            |
	
	
[3-step transaction]
	
  (3-step.1) Request is lost: A gets Timeout
	
                Same as (2-step.1)
	
  (3-step.2) Response is lost: A and B gets Timeout
	
                 A            B
   Send Add Req.	|            |
   + Start Timer |----------->| Recv Add Req.
                 |            |
                 |            | Send Res.
                 |    Res. x<-| + Start Timer
         Timeout |            |
                 |            |
                 |            |
                 |            | Timeout
	
  (3-step.3) Confirmation is lost: B gets Timeout
	
                 A            B
   Send Add Req.	|            |
   + Start Timer |----------->| Recv Add Req.
                 |            |
                 |            | Send Res.
   Recv Res.     |<-----------| + Start Timer
   + Stop Timer  |            |
                 |            |
   Send Conf.    |->x Conf.   |
                 |            | Timeout
			
  (3-step.4) Everything is fine: no timeout
			
                 A            B
   Send Add Req.	|            |
   + Start Timer |----------->| Recv Add Req.
                 |            |
                 |            | Send Res.
   Recv Res.     |<-----------| + Start Timer
   + Stop Timer  |            |
                 |            |
   Send Conf.    |----------->| Recv Conf.
                 |            | + Stop Timer
			
Hope these pictures are displayed correctly.
			
Best,
Yatch