Subject: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 3 Mar 2016 12:30:38 -0300

Dear all,
            In order to continue the discussion we left
unfinished at the Interim meeting in March 26th, I
will open a number of threads to take action on several
pending issues for the drafts:

draft-wang-6tisch-6top-sublayer-04 (which will be renamed to 6top-protocol)
draft-dujovne-6tisch-6top-sf0-00

- Regarding the use of a Token to identify transactions on
the 6top protocol, there was a proposal on the call to add
an 8-bit field to the packet header.

Do you agree with this solution?

Regards,

                              Diego Dujovne

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Tengfei Chang <[email-masked]>
Date: Thu, 3 Mar 2016 18:47:53 +0100

Hello Diego,

For the Token to identify the transaction, personally, if *the idea is to
identify a request and a response with a token*,  it can be replaced by
implementing a status machine, in which the status is able to identify the
status of 6P transaction.

Here is a rough example which is able to explain how Status Machine works:

*Initially* the status of 6P can be set as 6P_IDLE.

*For a mote sending 6p request:*

   1.  after the 6p request is ready to be sent which contains the
   candidate cell, the status turns to 6P_REQUEST_INIT
   2. after the request is sent, the status turns to
   6P_REQUEST_WAITING_RESPONSE
   3. after received the response from parent, mote sends ACK back and
   add/delete cell in schedule. The status turns to 6P_IDLE

*For a mote received 6p request:*

   1. after receiving the 6p request, the mote turns status to
   6P_RECEIVED_REQUEST
   2. when cells are selected or no cell is available, set status to
   6P_RESPONSE_TOBESENT
   3. after sending the response and get the ACK, mote will add/delete
   cells in schedule and set status back to 6P_IDLE

If the mote will not process the next 6P request if the status is correct.
Even if there are some issue that the mote stuck at one status, the timeout
will reset the status to 6P_IDLE.

With this, one byte can be save, though it's not that much.
What do you think?

Tengfei

On Thu, Mar 3, 2016 at 4:30 PM, Prof. Diego Dujovne <
[email-masked]> wrote:

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

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 3 Mar 2016 20:23:39 +0100

Hi Tengfei,

if we want (now or in the future) to support asynchronous responses (such
as the piggybacking case or if we want to aggregate confirmations) then the
token is handy. If we think that this mechanism will always be synchronous
and that concurrency will not be allowed then the state machine works.

my 2 cents :)
X

---

From: Tengfei Chang <[email-masked]>
Date: Fri, 4 Mar 2016 09:17:09 +0100

Hi Xavi,

Thanks for explanation! It makes sense for me.

Xavi, Diego, All,

Does the token indicates the ID of one transaction? How this 8-bits value
changes during a transaction/multiple transaction? It would be helpful if
there is some martial showing how the token works with 6p. Let me know if
there is also a discussion somewhere which I can trace. Thanks!

Tengfei

On Thu, Mar 3, 2016 at 8:23 PM, Xavier Vilajosana <
[email-masked]> wrote:

>> For the Token to identify the transaction, personally, if *the idea is
>> to identify a request and a response with a token*,  it can be replaced
>> by implementing a status machine, in which the status is able to identify
>> the status of 6P transaction.
>>
>> If the mote will not process the next 6P request if the status is
>> correct. Even if there are some issue that the mote stuck at one status,
>> the timeout will reset the status to 6P_IDLE.
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Mar 2016 11:37:21 +0000

One issue with that, Tengfei, is if the 6p response is sent but not received.

The client will retry the request for the same need of bandwidth but will get a new set of cells.
The parent that allocates cells must correlate them with a request ID (token, sequence, whatever) in case that request is retried so as to respond with the same cells.

Take care,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Tengfei Chang
Sent: jeudi 3 mars 2016 18:48
To: Prof. Diego Dujovne <[email-masked]>
Cc: [email-masked]
Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

Hello Diego,

For the Token to identify the transaction, personally, if the idea is to identify a request and a response with a token,  it can be replaced by implementing a status machine, in which the status is able to identify the status of 6P transaction.

Initially the status of 6P can be set as 6P_IDLE.

For a mote sending 6p request:

  1.   after the 6p request is ready to be sent which contains the candidate cell, the status turns to 6P_REQUEST_INIT
  2.  after the request is sent, the status turns to 6P_REQUEST_WAITING_RESPONSE
  3.  after received the response from parent, mote sends ACK back and add/delete cell in schedule. The status turns to 6P_IDLE
For a mote received 6p request:

  1.  after receiving the 6p request, the mote turns status to 6P_RECEIVED_REQUEST
  2.  when cells are selected or no cell is available, set status to 6P_RESPONSE_TOBESENT
  3.  after sending the response and get the ACK, mote will add/delete cells in schedule and set status back to 6P_IDLE
If the mote will not process the next 6P request if the status is correct. Even if there are some issue that the mote stuck at one status, the timeout will reset the status to 6P_IDLE.

Tengfei

On Thu, Mar 3, 2016 at 4:30 PM, Prof. Diego Dujovne <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
(56 2) 676 8125

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

---

From: Tengfei Chang <[email-masked]>
Date: Fri, 4 Mar 2016 14:06:28 +0100

Hi Pascal,

The parent should allocate cells only when it received the ACK of the
response. If no ACK received, no cell will be allocated. This can be
handled by state machine, though it doesn't support concurrency.

Tengfei

On Fri, Mar 4, 2016 at 12:37 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> The parent that allocates cells must correlate them with a request ID
> (token, sequence, whatever) in case that request is retried so as to
> respond with the same cells.
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Tengfei
> Chang
> *Sent:* jeudi 3 mars 2016 18:48
> *To:* Prof. Diego Dujovne <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] 6P and Sf0 issue: Token to identify transactions
> in 6P
>
>
>
> Hello Diego,
>
>
>
> For the Token to identify the transaction, personally, if * the idea is

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Mar 2016 13:26:11 +0000

Hello Tengfei

But if the ack is sent and not received then the parent does not allocate the cells and the child uses them...

And if a transaction hangs in the middle - say the child dies or is out of reach - then we'd have a deadlock.

No, as Xavi said we must plan for parallel transaction and roll back on error and time out.

Cheers,

Pascal

Le 4 mars 2016 ? 14:06, Tengfei Chang <[email-masked]<mailto:[email-masked]>> a ?crit :

Hi Pascal,

The parent should allocate cells only when it received the ACK of the response. If no ACK received, no cell will be allocated. This can be handled by state machine, though it doesn't support concurrency.

Tengfei

On Fri, Mar 4, 2016 at 12:37 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
One issue with that, Tengfei, is if the 6p response is sent but not received.

Take care,

Pascal

From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tengfei Chang
Sent: jeudi 3 mars 2016 18:48
To: Prof. Diego Dujovne <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

Hello Diego,

Tengfei

--
DIEGO DUJOVNE
Acad?mico Escuela de Ingenier?a en Inform?tica y Telecomunicaciones
Facultad de Ingenier?a UDP
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
(56 2) 676 8125

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 7 Mar 2016 15:24:13 +0200

Pascal Thubert (pthubert) writes:
> But if the ack is sent and not received then the parent does not
> allocate the cells and the child uses them...

And ACK only tells you that the frame was received, it does NOT mean
that the frame was processed. I.e. the recipient end might send an
ACK, and then send the frame to the upper layer, but if there is not
enough buffer space available there, it might drop it before it
actually reaches the upper layer.

So do not use ACK for anything else than indication that there is no
need to retransmit this frame anymore as other end already received it
(altough it might have dropped it after that, but retransmissions does
not help with that).
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Mar 2016 07:30:04 +0000

Sure, Tero; 

But this is another discussion entirely. It is about the transaction that associates new timeslots to a bundle and why we need a correlator, or transaction ID. I was explaining that if the parent wait for the ack to allocate a slot that was negotiated, and there is no flow after that, then if the ack is lost the child thinks the slot is allocated and the parent does not. The child may start using it wrongly. 

The point behind this is that if the transaction does not complete, it must be retried from scratch with the same sequence, or it must time out and roll back.

Cheers,

Pascal

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]]
> Sent: lundi 7 mars 2016 14:24
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Tengfei Chang <[email-masked]>; [email-masked]; Prof. Diego
> Dujovne <[email-masked]>
> And ACK only tells you that the frame was received, it does NOT mean that
> the frame was processed. I.e. the recipient end might send an ACK, and then
> send the frame to the upper layer, but if there is not enough buffer space
> available there, it might drop it before it actually reaches the upper layer.
> 
> So do not use ACK for anything else than indication that there is no need to
> retransmit this frame anymore as other end already received it (altough it
> might have dropped it after that, but retransmissions does not help with
> that).
> --
> [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 8 Mar 2016 16:49:59 +0200

Pascal Thubert (pthubert) writes:
> But this is another discussion entirely. It is about the transaction
> that associates new timeslots to a bundle and why we need a
> correlator, or transaction ID. I was explaining that if the parent
> wait for the ack to allocate a slot that was negotiated, and there
> is no flow after that, then if the ack is lost the child thinks the
> slot is allocated and the parent does not. The child may start using
> it wrongly.  

Which is why you should not use ACK for anything like that, but
instead use application level messages for that kind of things. 

> The point behind this is that if the transaction does not complete,
> it must be retried from scratch with the same sequence, or it must
> time out and roll back.

Receiving or not receiving ACK should not cause transaction to
complete or not to complete, there must be some kind of application
level message to indicate that it was successful if that information
is needed in the peers.
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Mar 2016 15:10:17 +0000

Oh yes, Tero,

we agree on the bottom line and on your points.

Cheers,

Pascal

> Sent: mardi 8 mars 2016 15:50
> Subject: RE: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P
> 
> > wait for the ack to allocate a slot that was negotiated, and there is
> > no flow after that, then if the ack is lost the child thinks the slot
> > is allocated and the parent does not. The child may start using it
> > wrongly.
> 
> Which is why you should not use ACK for anything like that, but instead use
> application level messages for that kind of things.
> 
> > The point behind this is that if the transaction does not complete, it
> > must be retried from scratch with the same sequence, or it must time
> > out and roll back.
> 
> Receiving or not receiving ACK should not cause transaction to complete or
> not to complete, there must be some kind of application level message to
> indicate that it was successful if that information is needed in the peers.
> --
> [email-masked]

---

From: Qin Wang <[email-masked]>
Date: Tue, 8 Mar 2016 21:08:52 +0000 (UTC)

Hi all,
I'm not convinced that token is necessary yet. From the discussion in the last WG meeting, we have agreed that the Token is used in the 6P message exchange between neighbors. Based on the agreement, let's consider the two following scenarios.
(1) nodeA send ADD_Request(token=1) to nodeB, and not receive Response from nodeB before Timeout. Then, nodeA send ADD_Request(token=2) to nodeB, and receive Response(token=2) from nodeB. 
(2) nodeA send ADD_Request to nodeB, and not receive Response from nodeB before Timeout. Then nodeA send ADD_Request to nodeB again, and receive Response from nodeB.

The question is if it is possible for nodeA to receive Response(token=1) from nodeB later in (1). Since nodeA will send the second ADD_Request after Timeout, I don't think it could happen. If I'm correct, I think the two sequences function similarly. Thus, I wonder if it is necessary to have the Token
What do you think?
ThanksQin

    On Tuesday, March 8, 2016 10:10 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:

 Oh yes, Tero,

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Mar 2016 07:13:02 +0000

Hello Qin:

Token 1 needs to be the same as token 2 when it is a retry. That's the whole point.

In your second case, say this is a child asking for a cell:

- If this is a time out because the response from the parent was lost, the parent should respond with the same cell as in the lost message.

- But if the child got the response and still needs more bandwidth, then the parent needs to allocate a second cell.

How does the parent know?

The main point of the sequence number is to be able to correlate the retry.

As it goes, it also enables to avoid the serialization of requests but I agree that is a non goal today.

Regards,

Pascal

Le 8 mars 2016 ? 22:10, Qin Wang <[email-masked]<mailto:[email-masked]>> a ?crit :

Hi all,

What do you think?

Thanks
Qin

On Tuesday, March 8, 2016 10:10 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Oh yes, Tero,

Cheers,

Pascal

> From: Tero Kivinen [mailto:[email-masked]<mailto:[email-masked]>]
> To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
> Cc: Tengfei Chang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Prof. Diego
> Dujovne <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>

---

From: Qin Wang <[email-masked]>
Date: Wed, 9 Mar 2016 15:47:46 +0000 (UTC)

Pascal,
I can see your point. Token is useful for Parent to distinguish Retry from new Request by the Child. 
But, I have a stupid question: is it reasonable to allow the Child to ask more cells before it gets Response to what it already asked?
ThanksQin 

    On Wednesday, March 9, 2016 2:13 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:

 Hello Qin:

Regards,
Pascal
Le 8 mars 2016 à 22:10, Qin Wang <[email-masked]> a écrit :

Hi all,

Oh yes, Tero,

Cheers,

Pascal

> Cc: Tengfei Chang <[email-masked]>;[email-masked]; Prof. Diego

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Mar 2016 17:27:16 +0000

Never seen a stupid question from you, Qin : )

I agree with you actually.

By “As it goes, it also enables to avoid the serialization of requests but I agree that is a non goal today.” I meant that the child will probably serialize hos requests, iow wait for one completion before it asks for more. But with the token / seqnum we are open if one day we decide otherwise…

Take care,

Pascal

From: Qin Wang [mailto:[email-masked]]
Sent: mercredi 9 mars 2016 16:48
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Tero Kivinen <[email-masked]>; [email-masked]; Prof. Diego Dujovne <[email-masked]>; Tengfei Chang <[email-masked]>
Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

Pascal,

Thanks
Qin

On Wednesday, March 9, 2016 2:13 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Qin:

Regards,

Pascal

Le 8 mars 2016 à 22:10, Qin Wang <[email-masked]<mailto:[email-masked]>> a écrit :
Hi all,

What do you think?

Thanks
Qin

Oh yes, Tero,

Cheers,

Pascal

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 11 Mar 2016 11:28:01 -0300

I agree with Xavi and Pascal on the use of the token:

- To enable future concurrent requests
- To enable retries.

However, in another thread Tengfei proposed that the SF should
take care of retries and 6P only respond to SFs as "OK" or "FAIL"
transaction.

Regards,

                                 Diego

2016-03-09 14:27 GMT-03:00 Pascal Thubert (pthubert) <[email-masked]>:

> By “As it goes, it also enables to avoid the serialization of requests
> but I agree that is a non goal today.” I meant that the child will
> probably serialize hos requests, iow wait for one completion before it asks
> for more. But with the token / seqnum we are open if one day we decide
> otherwise…
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* Qin Wang [mailto:[email-masked]]
> *Sent:* mercredi 9 mars 2016 16:48
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* Tero Kivinen <[email-masked]>; [email-masked]; Prof. Diego Dujovne
> <[email-masked]>; Tengfei Chang <[email-masked]>
> But, I have a stupid question: is it reasonable to allow the Child to ask
> more cells before it gets Response to what it already asked?
>
>
>
> Thanks
>
> Qin
>
>
>
> - If this is a time out because the response from the parent was lost, the
> parent should respond with the same cell as in the lost message.
>
>
>
> - But if the child got the response and still needs more bandwidth, then
> the parent needs to allocate a second cell.
>
>
>
> I'm not convinced that token is necessary yet. From the discussion in the
> last WG meeting, we have agreed that the Token is used in the 6P message
> exchange between neighbors. Based on the agreement, let's consider the two
> following scenarios.
>
>
>
> (1) nodeA send ADD_Request(token=1) to nodeB, and not receive Response
> from nodeB before Timeout. Then, nodeA send ADD_Request(token=2) to nodeB,
> and receive Response(token=2) from nodeB.
>
>
>
> (2) nodeA send ADD_Request to nodeB, and not receive Response from nodeB
> before Timeout. Then nodeA send ADD_Request to nodeB again, and receive
> Response from nodeB.
>
>
>
> The question is if it is possible for nodeA to receive Response(token=1)
> from nodeB later in (1). Since nodeA will send the second ADD_Request after
> Timeout, I don't think it could happen. If I'm correct, I think the two
> sequences function similarly. Thus, I wonder if it is necessary to have the
> Token
>
>
>
> What do you think?
>
>
>
> Thanks
>
> Qin
>
>
>
>
>

---

From: Tengfei Chang <[email-masked]>
Date: Sun, 13 Mar 2016 09:40:50 +0100

Diego,

I think it's two different things.

1. Token is capable to identify a retries or a new transaction. (As Pascal
said.)
2. SF decides whether retry or not. (It's said in another thread)

They are not collisions.

Tengfei

On Fri, Mar 11, 2016 at 3:28 PM, Prof. Diego Dujovne <
[email-masked]> wrote:

>> *Cc:* Tero Kivinen <[email-masked]>; [email-masked]; Prof. Diego
>> Dujovne <[email-masked]>; Tengfei Chang <
>> [email-masked]>
>> - If this is a time out because the response from the parent was lost,
>> the parent should respond with the same cell as in the lost message.
>>
>>
>>