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

From: Qin Wang <[email-masked]>
Date: Thu, 1 Dec 2016 20:45:29 +0000 (UTC)

Hi Yasuyuki,
I think nodeA=>nodeB request process includes two parts, one is Tx from nodeA to nodeB, another part is for nodeB's MAC to process the Request message. As you mentioned, failure of the first part can be identified by mac-ack from nodeB, but not the second part. Right?
ThanksQin  

    On Wednesday, November 30, 2016 1:49 PM, Yasuyuki Tanaka <[email-masked]> wrote:

 Thanks, Qin.

> (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?

That is right; failure in the nodeA=>nodeB case is what I called
"false positive." But, nodeA could lower the possibility of false
positive by using MAC-layer ACK, implementation efforts. If nodeA
doesn't receive a MAC-layer ACK to its request frame, nodeA can
consider the transaction as having failed without inconsistency.

> (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?

I'd say the generation counter is not the only way to detect
inconsistency. STATUS/LIST could detect it as well, although
STATUS/LIST always fails with RC_ERR_GEN in a case of inconsistency
according to the latest draft.

The generation counter can find inconsistency as you mentioned, but it
has disadvantages:

- It needs 6P to keep per-neighbor states (ignore SeqNum for now) even
  when there is no ongoing transaction.

- It cannot detect inconsistency until a subsequent transaction; it
  may take a long time.

The reactive approach using timeout doesn't have such disadvantages;
furthermore, it's simpler than the the schedule generation management,
in my opinion.

I still cannot see why the generation management at 6P is really needed...

Best,
Yatch

On 2016/11/30 17:39, Qin Wang wrote:
> 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?
>
> Thanks
> Qin

_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 1 Dec 2016 22:34:50 +0100

Hi Qin,

> I think nodeA=>nodeB request process includes two parts, one is Tx
> from nodeA to nodeB, another part is for nodeB's MAC to process the
> Request message. As you mentioned, failure of the first part can be
> identified by mac-ack from nodeB, but not the second part. Right?

Yes, that's right! I believe we are now on the same page about the
approach using timeout.

In this sense, ability to identify failure without inconsistency
occurred in the second part is the only advantage of the generation
counter, which is achieved by consuming four bits in every 6P packet
and keeping inter-transaction state for every neighbor. In my opinion,
this advantage is a little thing for the price to pay...

Best,
Yatch

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Fri, 2 Dec 2016 05:11:17 +0100

HI Yatch,

thanks for your comments. Could you please summarize how the timeout will
work in the 2 and 3 step transactions:

I see it in this way:
2-step
A sends to B an ADD, if A packet is lost, B will never realize and A will
timeout. Idem if B response fails ( A timeouts)

3-step
A sends to B an ADD. If A packet is lost, B never realizes and A timeouts.
If B receives the packet but Response fails. A timeouts as before and B
timeouts for not receiving the confirmation. If the confirmation is lost B
timeouts and A should cancel or timeout because it does not receive ACK at
the MAC layer.

Is this your suggestion?

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?

thanks!
X

2016-12-01 22:34 GMT+01:00 Yasuyuki Tanaka <[email-masked]>:

>> I think nodeA=>nodeB request process includes two parts, one is Tx from
>> nodeA to nodeB, another part is for nodeB's MAC to process the Request
>> message. As you mentioned, failure of the first part can be identified by
>> mac-ack from nodeB, but not the second part. Right?
>>
>> Thanks
>> Qin
>>
>>

-- 
Dr. Xavier Vilajosana Guillén
Research Professor
Wireless Networks Research Group
Internet Interdisciplinary Institute (IN3)
Universitat Oberta de Catalunya

+34 646 633 681| [email-masked] | Skype: xvilajosana
http://xvilajosana.org
http://wine.rdi.uoc.edu/

Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 5. Edifici B3
08860 Castelldefels (Barcelona)

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Fri, 2 Dec 2016 15:00:21 +0100

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