Subject: [6tisch] New error type for concurrent transactions on 6top protocol draft

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 13 May 2016 11:47:05 -0300

Dear all,
           I proposed today to add a new type of error
for CellList proposal during the transaction. The idea
follows the solution proposed today at the Webex call
by Xavi to define a lock when two concurrent cell
requests arrive to the node.
For example, if node B requests a cell from A,
and during this transaction node C requests a new
cell from A, send a  Concurrent Transaction "CT_ERROR"
so C knows there may still be resources available and
retry later instead of giving up.

Do you think this should solve the problem?

Regards,

                              Diego

-- 
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: Xavier Vilajosana <[email-masked]>
Date: Sat, 14 May 2016 15:03:36 +0200

Hi Diego,

What I propose is to lock in the schedule the cells that are being sent in
the candidate list, this means that 1) if there are other cells available
in the schedule, the node may still be able to propose another
(non-overlapping) candidate list. thus still supporting concurrency and 2)
only in the case that the remaining free cells are those in the candidate
list, the error code you propose will be used to enable a retry.

hope this is clear now!
X

2016-05-13 16:47 GMT+02:00 Prof. Diego Dujovne <[email-masked]>:

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

---

From: "Lijo Thomas" <[email-masked]>
Date: Wed, 18 May 2016 16:09:21 +0530

Hi Xavi/Diego,

Can’t we use the RC_BUSY rather than CT_ERROR  for the case of Concurrent transactions.  

The scheduling function may decide for a retry when a RC_BUSY is received , so how we can differentiate the usage of CT_ERROR and RC_BUSY.

Is it the backoff time that accounts.  

Thanks & Regards,

Lijo Thomas 

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: 14 May 2016 18:34
To: Prof. Diego Dujovne
Cc: [email-masked]
Subject: Re: [6tisch] New error type for concurrent transactions on 6top protocol draft

Hi Diego,

What I propose is to lock in the schedule the cells that are being sent in the candidate list, this means that 1) if there are other cells available in the schedule, the node may still be able to propose another (non-overlapping) candidate list. thus still supporting concurrency and 2) only in the case that the remaining free cells are those in the candidate list, the error code you propose will be used to enable a retry.

hope this is clear now!

X

2016-05-13 16:47 GMT+02:00 Prof. Diego Dujovne <[email-masked] <mailto:[email-masked]> >:

Dear all,

Regards,

                              Diego

-- 

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

-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 18 May 2016 14:21:48 +0200

Hi,

the current 6top draft v00 says:

   A node MAY support concurrent 6P Transactions from different
   neighbors.  In this case, in Figure 1, node C can have a different
   ongoing 6P Transaction with nodes B and E.  In case a node does not
   have enough resources to handle concurrent 6P Transactions from
   different neighbors, when it receives a 6P Request from a neighbor
   while already handling a different request from a different neighbor,
   it MUST reply to that second request with a 6P Response with return
   code IANA_6TOP_RC_BUSY.

This indicates that if there aren't enough resources to handle the
transaction it responds with the RC_BUSY.

If we want to further clarify the case of locking the cells in the
candidate list we can add a text like

"The cells in a candidate list are locked in the schedule until the
transaction has finished or the cells definitely allocated. Upon completion
of the transaction the non-allocated cells are released and can be used for
other transactions. During a concurrent transaction, the cells advertised
in a cell list MUST not overlap to cells advertised to other neighbors
concurrently. In case that the a node has not enough resources to handle
the concurrent transactions as some cells are locked, the code
IANA_6TOP_RC_BUSY MUST be returned to one or more of the requesting nodes
enabling them to retry."

In this case we use RC_BUSY again, but as proposed by Diego we may decide
to use another error code to differentiate this case. IMHO RC_BUSY is
enough though.

what do you think?
X

2016-05-18 12:39 GMT+02:00 Lijo Thomas <[email-masked]>:

> The scheduling function may decide for a retry when a RC_BUSY is received
> , so how we can differentiate the usage of CT_ERROR and RC_BUSY.
>
>
>
> *Thanks & Regards,*
> *Lijo Thomas *
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Xavier
> Vilajosana
> *Sent:* 14 May 2016 18:34
> *To:* Prof. Diego Dujovne
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] New error type for concurrent transactions on
> 6top protocol draft
>
>
>
> Hi Diego,
>
>
>
> 2016-05-13 16:47 GMT+02:00 Prof. Diego Dujovne <[email-masked]
> >:
>
> Dear all,
>
> *MailScanner has detected a possible fraud attempt from
> "www.ingenieria.udp..cl" claiming to be* www.ingenieria.udp.cl
> <http://www.ingenieria.udp..cl>
> (56 2) 676 8125
>
>

---

From: "Lijo Thomas" <[email-masked]>
Date: Wed, 18 May 2016 18:53:29 +0530

Hi Xavi,

Thanks for the detailed one.

Yes I am of the opinion of using the same RC_BUSY itself, but at the same time we should modify the text as indicated by you, so that locking mechanisms are clearly mentioned. Also it  states the options for retry in case of concurrent transactions.

With the keyword RC_BUSY, one expects that the node is indulge in a 6P transaction currently and can go for a retry.  But in the draft it says RC_BUSY with no resources available. It is bit confusing.

Thanks & Regards,

Lijo Thomas 

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: 18 May 2016 17:52
To: Lijo Thomas
Cc: [email-masked]; Prof. Diego Dujovne
Subject: Re: [6tisch] New error type for concurrent transactions on 6top protocol draft

Hi,

   code IANA_6TOP_RC_BUSY.

This indicates that if there aren't enough resources to handle the transaction it responds with the RC_BUSY.

If we want to further clarify the case of locking the cells in the candidate list we can add a text like

"The cells in a candidate list are locked in the schedule until the transaction has finished or the cells definitely allocated. Upon completion of the transaction the non-allocated cells are released and can be used for other transactions. During a concurrent transaction, the cells advertised in a cell list MUST not overlap to cells advertised to other neighbors concurrently. In case that the a node has not enough resources to handle the concurrent transactions as some cells are locked, the code IANA_6TOP_RC_BUSY MUST be returned to one or more of the requesting nodes enabling them to retry."

In this case we use RC_BUSY again, but as proposed by Diego we may decide to use another error code to differentiate this case. IMHO RC_BUSY is enough though.

what do you think?

X

 

2016-05-18 12:39 GMT+02:00 Lijo Thomas <[email-masked] <mailto:[email-masked]> >:

Hi Xavi/Diego,

Thanks & Regards,

Lijo Thomas 

From: 6tisch [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Xavier Vilajosana
Sent: 14 May 2016 18:34
To: Prof. Diego Dujovne
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [6tisch] New error type for concurrent transactions on 6top protocol draft

Hi Diego,

hope this is clear now!

X

Dear all,

Regards,

                              Diego

-- 

DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
 <http://www.ingenieria.udp..cl> MailScanner has detected a possible fraud attempt from "www.ingenieria.udp..cl" claiming to be www.ingenieria.udp.cl
(56 2) 676 8125

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Wed, 18 May 2016 13:47:53 -0300

Lijo, Xavi:
              I would like to point out that the idea of having
another type of error is to differentiate the lack of processing/storage
power to complete a new transaction from the concurrent transaction
condition, giving a better clue of what is going on to the requesting
node and to enable to calculate a different retry interval for each case.
A transaction should not take more than 3 exchanges, so this should
be the retry period for the concurrent case.

To be brief:

RC_BUSY: "I am overloaded"

CT_ERROR: "I have very few available cells remaining, try on the next cycle"

Regards,

                               Diego Dujovne

2016-05-18 9:23 GMT-04:00 Lijo Thomas <[email-masked]>:

> Yes I am of the opinion of using the same RC_BUSY itself, but at the same
> time we should modify the text as indicated by you, so that locking
> mechanisms are clearly mentioned. Also it  states the options for retry in
> case of concurrent transactions.
>
>
>
> With the keyword RC_BUSY, one expects that the node is indulge in a 6P
> transaction currently and can go for a retry.  But in the draft it says
> RC_BUSY with no resources available. It is bit confusing.
>
>
>
>
>
> *Thanks & Regards,*
>
> *Lijo Thomas *
>
>
>
>
>
> *Sent:* 18 May 2016 17:52
> *To:* Lijo Thomas
> *Cc:* [email-masked]; Prof. Diego Dujovne
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 19 May 2016 08:32:54 +0200

Hola Diego,

according to the 6top draft:

the sentence:

" node does not have enough resources to handle concurrent 6P Transactions "

does not preclude what "resources" mean. They can be as you say
processing/storage capabilities or instead available cells in the schedule.
As far as I understand both cases apply to concurrent transactions and I
tend to think of the second meaning when I read the sentence.  For me
differentiating both can lead to start differentiating tens particular
cases.  I think that we want to avoid that and keep things as simple as
possible.

In either case, the SF will decide a retry, so why differentiate it? Why
different timing in both situations? At the end this is a contention
problem which the SF can handle with a specific back-off mechanism.

regards!!
X

2016-05-18 18:47 GMT+02:00 Prof. Diego Dujovne <[email-masked]>:

>> What I propose is to lock in the schedule the cells that are being sent
>> in the candidate list, this means that 1) if there are other cells
>> available in the schedule, the node may still be able to propose another

---

From: "Lijo Thomas" <[email-masked]>
Date: Thu, 19 May 2016 14:11:29 +0530

Hi,

I agree with Xavi.

Let the scheduling function handles the timing based on the application.

So it’s better to keep the RC_BUSY itself and modify the draft as per Xavi’s suggestion in the trailing mails.

Thanks & Regards,

Lijo Thomas 

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: 19 May 2016 12:03
To: Prof. Diego Dujovne
Cc: Lijo Thomas; [email-masked]
Subject: Re: [6tisch] New error type for concurrent transactions on 6top protocol draft

Hola Diego,

   code IANA_6TOP_RC_BUSY.

the sentence:

does not preclude what "resources" mean. They can be as you say processing/storage capabilities or instead available cells in the schedule. As far as I understand both cases apply to concurrent transactions and I tend to think of the second meaning when I read the sentence.  For me differentiating both can lead to start differentiating tens particular cases.  I think that we want to avoid that and keep things as simple as possible. 

In either case, the SF will decide a retry, so why differentiate it? Why different timing in both situations? At the end this is a contention problem which the SF can handle with a specific back-off mechanism.

regards!!

X

2016-05-18 18:47 GMT+02:00 Prof. Diego Dujovne <[email-masked]..cl <mailto:[email-masked]> >:

Lijo, Xavi:

To be brief:

Regards,

                               Diego Dujovne

2016-05-18 9:23 GMT-04:00 Lijo Thomas <[email-masked] <mailto:[email-masked]> >:

Hi Xavi,

 

Thanks & Regards,

Lijo Thomas 

From: 6tisch [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Xavier Vilajosana
Sent: 18 May 2016 17:52
To: Lijo Thomas
Cc: [email-masked] <mailto:[email-masked]> ; Prof. Diego Dujovne

Hi,

   code IANA_6TOP_RC_BUSY.

what do you think?

X

 

Hi Xavi/Diego,

Thanks & Regards,

Lijo Thomas 

Hi Diego,

hope this is clear now!

X

Dear all,

Regards,

                              Diego

-- 

DIEGO DUJOVNE

------------------------------------------------------------------------------------------------------------------------------- 
[ C-DAC is on Social-Media too. Kindly follow us at: 
Facebook: https://www..facebook.com/CDACINDIA <https://www.facebook.com/CDACINDIA>  & Twitter: @cdacindia ] 

-- 

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: Thomas Watteyne <[email-masked]>
Date: Mon, 23 May 2016 14:32:38 +0200

All,

We have reached a consensus, in summary:
- a 6P transaction is not infinitely fast, we need to guarantee atomicity
of the cell reservation process
- In case of concurrent transactions involving the same cells on a
particular node, that node need to be able to "lock" access to those cells
during a particular 6P transaction.
- in case node A initiates a 6P negociation to node B, and specifies cells
which are in "locked" in B's schedule, B answers with a RC_BUSY return code

The following rewording was proposed:

OLD
A node MAY support concurrent 6P Transactions from different
neighbors.  In this case, in Figure 1, node C can have a different
ongoing 6P Transaction with nodes B and E.  In case a node does not
have enough resources to handle concurrent 6P Transactions from
different neighbors, when it receives a 6P Request from a neighbor
while already handling a different request from a different neighbor,
it MUST reply to that second request with a 6P Response with return
code IANA_6TOP_RC_BUSY.
NEW
The cells in a candidate list are locked in the schedule until the
transaction has finished or the cells definitely allocated.
Upon completion of the transaction the non-allocated cells are released and
can be used for other transactions.
During a concurrent transaction, the cells advertised in a cell list MUST
not overlap to cells advertised to other neighbors concurrently.
In case that the a node has not enough resources to handle the concurrent
transactions as some cells are locked, the code IANA_6TOP_RC_BUSY MUST be
returned to one or more of the requesting nodes enabling them to retry.

The last step is for us to agree on the exact wording. What about the
following (editorial chages only, trying to merge the OLD/NEW text above)

===================== start proposed NEW2
A node MAY support concurrent 6P Transactions from different neighbors.
In this case, in Figure 1, node C can have a different ongoing 6P
Transaction with nodes B and E.

In case a node does not have enough resources to handle concurrent 6P
Transactions from different neighbors, when it receives a 6P Request from a
neighbor while already handling a different request from a different
neighbor, it MUST reply to that second request with a 6P Response with
return code IANA_6TOP_RC_BUSY.

In case concurrent transactions are supported, the protocol needs to
guarantee atomicity.
If concurrent transactions are supported, during a particular transaction,
the cells involved in that transaction MUST be locked until the transaction
finishes.
When transaction finishes, those cells are either allocated, or released.
If a node receives a transaction while another transaction is ongoing, and
that subsequent transaction involved the same cells, the mote MUST reply to
that second request with a 6P Response with return code IANA_6TOP_RC_BUSY.
===================== end proposed NEW2

One thing which isn't clear is what happens if in the second transaction,
only a subset of the cells in the 6P request are in locked state.

Edit at will.

Thomas

On Thu, May 19, 2016 at 10:41 AM, Lijo Thomas <[email-masked]> wrote:

> *Sent:* 19 May 2016 12:03
> *Cc:* Lijo Thomas; [email-masked]
> 2016-05-18 18:47 GMT+02:00 Prof. Diego Dujovne <[email-masked]..cl
> <[email-masked]>>:
>
> Lijo, Xavi:
>
> Facebook: https://www..facebook.com/CDACINDIA
> <https://www.facebook.com/CDACINDIA> & Twitter: @cdacindia ]
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: "Lijo Thomas" <[email-masked]>
Date: Tue, 24 May 2016 11:46:24 +0530

Hi Thomas,
 
I feel that we should group the RC_BUSY cases.  
 
My suggestion : >>>
 
A node MAY support concurrent 6P Transactions from different neighbors.  In this case the cells involved in the ongoing 6P transaction MUST be locked until the transaction finishes. For example, in Figure 1, node C can have a different ongoing 6P Transaction with nodes B and E.  
 
In case a node does not have enough resources to handle concurrent 6P Transactions from different neighbors or if the cells requested are locked, it MUST reply to that second request with a 6P Response with return code IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement a retry as decided by the Scheduling Function

Does it make sense ..
 
Thanks & Regards,
Lijo Thomas 

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: 23 May 2016 18:03
To: Lijo Thomas
Cc: [email-masked]; Prof. Diego Dujovne; Xavier Vilajosana
Subject: Re: [6tisch] New error type for concurrent transactions on 6top protocol draft
 
All,
 
We have reached a consensus, in summary:
- a 6P transaction is not infinitely fast, we need to guarantee atomicity of the cell reservation process
- In case of concurrent transactions involving the same cells on a particular node, that node need to be able to "lock" access to those cells during a particular 6P transaction.
- in case node A initiates a 6P negociation to node B, and specifies cells which are in "locked" in B's schedule, B answers with a RC_BUSY return code

OLD
A node MAY support concurrent 6P Transactions from different
neighbors.  In this case, in Figure 1, node C can have a different
ongoing 6P Transaction with nodes B and E.  In case a node does not
have enough resources to handle concurrent 6P Transactions from
different neighbors, when it receives a 6P Request from a neighbor
while already handling a different request from a different neighbor,
it MUST reply to that second request with a 6P Response with return
code IANA_6TOP_RC_BUSY.
NEW
The cells in a candidate list are locked in the schedule until the transaction has finished or the cells definitely allocated.
Upon completion of the transaction the non-allocated cells are released and can be used for other transactions.
During a concurrent transaction, the cells advertised in a cell list MUST not overlap to cells advertised to other neighbors concurrently.
In case that the a node has not enough resources to handle the concurrent transactions as some cells are locked, the code IANA_6TOP_RC_BUSY MUST be returned to one or more of the requesting nodes enabling them to retry.
 
The last step is for us to agree on the exact wording. What about the following (editorial chages only, trying to merge the OLD/NEW text above)
 
===================== start proposed NEW2
A node MAY support concurrent 6P Transactions from different neighbors.
In this case, in Figure 1, node C can have a different ongoing 6P Transaction with nodes B and E.
 
In case a node does not have enough resources to handle concurrent 6P Transactions from different neighbors, when it receives a 6P Request from a neighbor while already handling a different request from a different neighbor, it MUST reply to that second request with a 6P Response with return code IANA_6TOP_RC_BUSY.
 
In case concurrent transactions are supported, the protocol needs to guarantee atomicity.
If concurrent transactions are supported, during a particular transaction, the cells involved in that transaction MUST be locked until the transaction finishes.
When transaction finishes, those cells are either allocated, or released.
If a node receives a transaction while another transaction is ongoing, and that subsequent transaction involved the same cells, the mote MUST reply to that second request with a 6P Response with return code IANA_6TOP_RC_BUSY.
===================== end proposed NEW2
 
One thing which isn't clear is what happens if in the second transaction, only a subset of the cells in the 6P request are in locked state.
 
Edit at will. 
 
Thomas

 
On Thu, May 19, 2016 at 10:41 AM, Lijo Thomas < <mailto:[email-masked]> [email-masked]> wrote:
Hi,
 
I agree with Xavi.

Thanks & Regards,
Lijo Thomas 
 
From: 6tisch [mailto: <mailto:[email-masked]> [email-masked]] On Behalf Of Xavier Vilajosana
Sent: 19 May 2016 12:03
To: Prof. Diego Dujovne
Cc: Lijo Thomas;  <mailto:[email-masked]> [email-masked]
Subject: Re: [6tisch] New error type for concurrent transactions on 6top protocol draft
 
Hola Diego,

the sentence:

 
 
regards!!
X
 
2016-05-18 18:47 GMT+02:00 Prof. Diego Dujovne < <mailto:[email-masked]> [email-masked]..cl>:
Lijo, Xavi:
 
To be brief:
 
Regards,
                               Diego Dujovne

2016-05-18 9:23 GMT-04:00 Lijo Thomas < <mailto:[email-masked]> [email-masked]>:
Hi Xavi,

 

Thanks & Regards,
Lijo Thomas 

From: 6tisch [mailto: <mailto:[email-masked]> [email-masked]] On Behalf Of Xavier Vilajosana
Sent: 18 May 2016 17:52
To: Lijo Thomas
Cc:  <mailto:[email-masked]> [email-masked]; Prof. Diego Dujovne

Hi,

 

 
 
what do you think?
X

2016-05-18 12:39 GMT+02:00 Lijo Thomas < <mailto:[email-masked]> lijo@cdac..in>:
Hi Xavi/Diego,

 
 
Thanks & Regards,
Lijo Thomas 

From: 6tisch [mailto: <mailto:[email-masked]> [email-masked]] On Behalf Of Xavier Vilajosana
Sent: 14 May 2016 18:34
To: Prof. Diego Dujovne
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [6tisch] New error type for concurrent transactions on 6top protocol draft
 
Hi Diego,

hope this is clear now!
X
 
2016-05-13 16:47 GMT+02:00 Prof. Diego Dujovne < <mailto:[email-masked]> [email-masked]>:
Dear all,

Regards,
                              Diego

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

------------------------------------------------------------------------------------------------------------------------------- 
[ C-DAC is on Social-Media too. Kindly follow us at: 
Facebook:  <https://www.facebook.com/CDACINDIA> https://www..facebook.com/CDACINDIA & Twitter: @cdacindia ] 

------------------------------------------------------------------------------------------------------------------------------- 
[ C-DAC is on Social-Media too. Kindly follow us at: 
Facebook:  <https://www.facebook.com/CDACINDIA> https://www..facebook.com/CDACINDIA & Twitter: @cdacindia ] 

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

------------------------------------------------------------------------------------------------------------------------------- 
[ C-DAC is on Social-Media too. Kindly follow us at: 
Facebook:  <https://www.facebook.com/CDACINDIA> https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] 

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

 
Thomas Watteyne, PhD
 
 <http://www.thomaswatteyne.com> www.thomaswatteyne.com
_______________________________________

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 24 May 2016 13:39:55 +0200

Lijo,

Looks good to me. A tiny typo:

===
A node MAY support concurrent 6P Transactions from different neighbors.  In
this case the cells involved in the ongoing 6P transaction MUST be locked
until the transaction finishes. For example, in Figure 1, node C can have a
different ongoing 6P Transaction with nodes B and E.

In case a node does not have enough resources to handle concurrent 6P
Transactions from different neighbors or if the cells requested are locked,
it MUST reply to that second request with a 6P Response with return code
IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement a
retry mechanism, as decided by the Scheduling Function.
===

Any further comments/suggestions?

Thomas

On Tue, May 24, 2016 at 8:16 AM, Lijo Thomas <[email-masked]> wrote:

> A node MAY support concurrent 6P Transactions from different neighbors.  In
> this case the cells involved in the ongoing 6P transaction MUST be locked
> until the transaction finishes. For example, in Figure 1, node C can have a
> different ongoing 6P Transaction with nodes B and E.
>
>
>
> Transactions from different neighbors or if the cells requested are
> locked, it MUST reply to that second request with a 6P Response with return
> code IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement
> a retry as decided by the Scheduling Function
>
>
>
> >>>>>>>
>
>
>
> Does it make sense ..
>
>
>
> *Thanks & Regards,*
>
> *Lijo Thomas *
>
>
>
>
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Thomas
> Watteyne
> *Sent:* 23 May 2016 18:03
> *To:* Lijo Thomas
> *Cc:* [email-masked]; Prof. Diego Dujovne; Xavier Vilajosana
>
> 2016-05-18 12:39 GMT+02:00 Lijo Thomas <lijo@cdac..in <[email-masked]>>:
>
> Hi Xavi/Diego,
>
>
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 24 May 2016 16:18:06 +0200

Looks good to me!

===

X

2016-05-24 13:39 GMT+02:00 Thomas Watteyne <[email-masked]>:

> In this case the cells involved in the ongoing 6P transaction MUST be
> locked until the transaction finishes. For example, in Figure 1, node C can
> have a different ongoing 6P Transaction with nodes B and E.
>
>> - in case node A initiates a 6P negociation to node B, and specifies
>> cells which are in "locked" in B's schedule, B answers with a RC_BUSY
>> return code
>>
>>
>>
>> If concurrent transactions are supported, during a particular
>> transaction, the cells involved in that transaction MUST be locked until
>> the transaction finishes.
>>
>> If a node receives a transaction while another transaction is ongoing,
>> and that subsequent transaction involved the same cells, the mote MUST
>> reply to that second request with a 6P Response with return code
>> IANA_6TOP_RC_BUSY.
>>
>> 2016-05-18 18:47 GMT+02:00 Prof. Diego Dujovne <
>> [email-masked]..cl <[email-masked]>>:
>>
>> Lijo, Xavi:
>>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Tue, 24 May 2016 12:28:57 -0300

Xavi, all:
              Going back on what you proposed and the revised
text, the ony difference I see between a specific error on concurrent
transactions and the busy error, is the possibility to choose between
different retry periods and the number of retries by the SF:
If a child desperately needs new cells, and the only problem
is concurrency, a short retry period and a high number of retries may
be the reaction, while if the error is busy due to resource
(=processor/storage)
constraints, then the reaction would be a longer retry period, or even
to give up the transaction.
             However, for the sake of simplicity, keeping the busy error
response does the job in a more generic way.
             Regards,

                                        Diego

2016-05-24 10:18 GMT-04:00 Xavier Vilajosana <[email-masked]>
:

>>> - a 6P transaction is not infinitely fast, we need to guarantee
>>> atomicity of the cell reservation process
>>>
>>> During a concurrent transaction, the cells advertised in a cell list
>>> MUST not overlap to cells advertised to other neighbors concurrently.
>>>
>>> In case that the a node has not enough resources to handle the
>>> concurrent transactions as some cells are locked, the code
>>> enabling them to retry.
>>> One thing which isn't clear is what happens if in the second
>>> transaction, only a subset of the cells in the 6P request are in locked
>>> state.
>>>
>>>
>>>
>>> Edit at will.
>>>
>>>
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Yes I am of the opinion of using the same RC_BUSY itself, but at the
>>> same time we should modify the text as indicated by you, so that locking
>>> In this case we use RC_BUSY again, but as proposed by Diego we may
>>> decide to use another error code to differentiate this case. IMHO RC_BUSY
>>> is enough though.
>>>
>>>
>>>
>>> what do you think?
>>>
>>> X
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> The scheduling function may decide for a retry when a RC_BUSY is
>>> received , so how we can differentiate the usage of CT_ERROR and RC_BUSY.
>>>
>>>
>>>

---

From: Qin Wang <[email-masked]>
Date: Wed, 25 May 2016 00:15:03 +0000 (UTC)

+1
Qin 

    On Tuesday, May 24, 2016 1:22 PM, Xavier Vilajosana <[email-masked]> wrote:

 Looks good to me!
===A node MAY support concurrent 6P Transactions from different neighbors.  In this case the cells involved in the ongoing 6P transaction MUST be locked until the transaction finishes. For example, in Figure 1, node C can have a different ongoing 6P Transaction with nodes B and E.  In case a node does not have enough resources to handle concurrent 6P Transactions from different neighbors or if the cells requested are locked, it MUST reply to that second request with a 6P Response with return code IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement a retry mechanism, as decided by the Scheduling Function.===
X
2016-05-24 13:39 GMT+02:00 Thomas Watteyne <[email-masked]>:

Lijo,
Looks good to me. A tiny typo:
===A node MAY support concurrent 6P Transactions from different neighbors.  In this case the cells involved in the ongoing 6P transaction MUST be locked until the transaction finishes. For example, in Figure 1, node C can have a different ongoing 6P Transaction with nodes B and E.  In case a node does not have enough resources to handle concurrent 6P Transactions from different neighbors or if the cells requested are locked, it MUST reply to that second request with a 6P Response with return code IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement a retry mechanism, as decided by the Scheduling Function.===
Any further comments/suggestions?
Thomas
On Tue, May 24, 2016 at 8:16 AM, Lijo Thomas <[email-masked]> wrote:

Hi Thomas, I feel that we should group the RC_BUSY cases.   My suggestion : >>> A node MAY support concurrent 6P Transactions from different neighbors.  In this case the cells involved in the ongoing 6P transaction MUST be locked until the transaction finishes. For example, in Figure 1, node C can have a different ongoing 6P Transaction with nodes B and E.   In case a node does not have enough resources to handle concurrent 6P Transactions from different neighbors or if the cells requested are locked, it MUST reply to that second request with a 6P Response with return code IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement a retry as decided by the Scheduling Function >>>>>>>  Does it make sense .. Thanks & Regards,Lijo Thomas   From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: 23 May 2016 18:03
To: Lijo Thomas
Cc: [email-masked]; Prof. Diego Dujovne; Xavier Vilajosana
Subject: Re: [6tisch] New error type for concurrent transactions on 6top protocol draft All, We have reached a consensus, in summary:- a 6P transaction is not infinitely fast, we need to guarantee atomicity of the cell reservation process- In case of concurrent transactions involving the same cells on a particular node, that node need to be able to "lock" access to those cells during a particular 6P transaction.- in case node A initiates a 6P negociation to node B, and specifies cells which are in "locked" in B's schedule, B answers with a RC_BUSY return code The following rewording was proposed: OLDA node MAY support concurrent 6P Transactions from differentneighbors.  In this case, in Figure 1, node C can have a differentongoing 6P Transaction with nodes B and E.  In case a node does nothave enough resources to handle concurrent 6P Transactions fromdifferent neighbors, when it receives a 6P Request from a neighborwhile already handling a different request from a different neighbor,it MUST reply to that second request with a 6P Response with returncode IANA_6TOP_RC_BUSY.NEWThe cells in a candidate list are locked in the schedule until the transaction has finished or the cells definitely allocated.Upon completion of the transaction the non-allocated cells are released and can be used for other transactions.During a concurrent transaction, the cells advertised in a cell list MUST not overlap to cells advertised to other neighbors concurrently.In case that the a node has not enough resources to handle the concurrent transactions as some cells are locked, the code IANA_6TOP_RC_BUSY MUST be returned to one or more of the requesting nodes enabling them to retry. The last step is for us to agree on the exact wording. What about the following (editorial chages only, trying to merge the OLD/NEW text above) ===================== start proposed NEW2A node MAY support concurrent 6P Transactions from different neighbors.In this case, in Figure 1, node C can have a different ongoing 6P Transaction with nodes B and E. In case a node does not have enough resources to handle concurrent 6P Transactions from different neighbors, when it receives a 6P Request from a neighbor while already handling a different request from a different neighbor, it MUST reply to that second request with a 6P Response with return code IANA_6TOP_RC_BUSY. In case concurrent transactions are supported, the protocol needs to guarantee atomicity.If concurrent transactions are supported, during a particular transaction, the cells involved in that transaction MUST be locked until the transaction finishes.When transaction finishes, those cells are either allocated, or released.If a node receives a transaction while another transaction is ongoing, and that subsequent transaction involved the same cells, the mote MUST reply to that second request with a 6P Response with return code IANA_6TOP_RC_BUSY.===================== end proposed NEW2 One thing which isn't clear is what happens if in the second transaction, only a subset of the cells in the 6P request are in locked state. Edit at will.  Thomas    On Thu, May 19, 2016 at 10:41 AM, Lijo Thomas <[email-masked]> wrote:
Hi, I agree with Xavi. Let the scheduling function handles the timing based on the application. So it’s better to keep the RC_BUSY itself and modify the draft as per Xavi’s suggestion in the trailing mails.  Thanks & Regards,Lijo Thomas  From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: 19 May 2016 12:03
To: Prof. Diego Dujovne
Cc: Lijo Thomas; [email-masked]
Subject: Re: [6tisch] New error type for concurrent transactions on 6top protocol draft Hola Diego, according to the 6top draft:   A node MAY support concurrent 6P Transactions from different   neighbors.  In this case, in Figure 1, node C can have a different   ongoing 6P Transaction with nodes B and E.  In case a node does not   have enough resources to handle concurrent 6P Transactions from   different neighbors, when it receives a 6P Request from a neighbor   while already handling a different request from a different neighbor,   it MUST reply to that second request with a 6P Response with return   code IANA_6TOP_RC_BUSY.  the sentence: " node does not have enough resources to handle concurrent 6P Transactions " does not preclude what "resources" mean. They can be as you say processing/storage capabilities or instead available cells in the schedule. As far as I understand both cases apply to concurrent transactions and I tend to think of the second meaning when I read the sentence.  For me differentiating both can lead to start differentiating tens particular cases.  I think that we want to avoid that and keep things as simple as possible.  In either case, the SF will decide a retry, so why differentiate it? Why different timing in both situations? At the end this is a contention problem which the SF can handle with a specific back-off mechanism. regards!!X 2016-05-18 18:47 GMT+02:00 Prof. Diego Dujovne <[email-masked]..cl>:
Lijo, Xavi:              I would like to point out that the idea of havinganother type of error is to differentiate the lack of processing/storagepower to complete a new transaction from the concurrent transaction 
condition, giving a better clue of what is going on to the requesting 
node and to enable to calculate a different retry interval for each case.A transaction should not take more than 3 exchanges, so this shouldbe the retry period for the concurrent case. To be brief:RC_BUSY: "I am overloaded"CT_ERROR: "I have very few available cells remaining, try on the next cycle" Regards,                               Diego Dujovne  2016-05-18 9:23 GMT-04:00 Lijo Thomas <[email-masked]>:
Hi Xavi, Thanks for the detailed one. Yes I am of the opinion of using the same RC_BUSY itself, but at the same time we should modify the text as indicated by you, so that locking mechanisms are clearly mentioned. Also it  states the options for retry in case of concurrent transactions. With the keyword RC_BUSY, one expects that the node is indulge in a 6P transaction currently and can go for a retry.  But in the draft it says RC_BUSY with no resources available. It is bit confusing.  Thanks & Regards,Lijo Thomas   From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: 18 May 2016 17:52
To: Lijo Thomas
Cc: [email-masked]; Prof. Diego Dujovne
Subject: Re: [6tisch] New error type for concurrent transactions on 6top protocol draft Hi, the current 6top draft v00 says:    A node MAY support concurrent 6P Transactions from different   neighbors.  In this case, in Figure 1, node C can have a different   ongoing 6P Transaction with nodes B and E.  In case a node does not   have enough resources to handle concurrent 6P Transactions from   different neighbors, when it receives a 6P Request from a neighbor   while already handling a different request from a different neighbor,   it MUST reply to that second request with a 6P Response with return   code IANA_6TOP_RC_BUSY. This indicates that if there aren't enough resources to handle the transaction it responds with the RC_BUSY. If we want to further clarify the case of locking the cells in the candidate list we can add a text like "The cells in a candidate list are locked in the schedule until the transaction has finished or the cells definitely allocated. Upon completion of the transaction the non-allocated cells are released and can be used for other transactions. During a concurrent transaction, the cells advertised in a cell list MUST not overlap to cells advertised to other neighbors concurrently. In case that the a node has not enough resources to handle the concurrent transactions as some cells are locked, the code IANA_6TOP_RC_BUSY MUST be returned to one or more of the requesting nodes enabling them to retry." In this case we use RC_BUSY again, but as proposed by Diego we may decide to use another error code to differentiate this case. IMHO RC_BUSY is enough though. what do you think?X     2016-05-18 12:39 GMT+02:00 Lijo Thomas <lijo@cdac..in>:
Hi Xavi/Diego, Can’t we use the RC_BUSY rather than CT_ERROR  for the case of Concurrent transactions.   The scheduling function may decide for a retry when a RC_BUSY is received , so how we can differentiate the usage of CT_ERROR and RC_BUSY. Is it the backoff time that accounts.   Thanks & Regards,Lijo Thomas   From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: 14 May 2016 18:34
To: Prof. Diego Dujovne
Cc: [email-masked]
Subject: Re: [6tisch] New error type for concurrent transactions on 6top protocol draft Hi Diego, What I propose is to lock in the schedule the cells that are being sent in the candidate list, this means that 1) if there are other cells available in the schedule, the node may still be able to propose another (non-overlapping) candidate list. thus still supporting concurrency and 2) only in the case that the remaining free cells are those in the candidate list, the error code you propose will be used to enable a retry. hope this is clear now!X 2016-05-13 16:47 GMT+02:00 Prof. Diego Dujovne <[email-masked]>:
Dear all,           I proposed today to add a new type of error for CellList proposal during the transaction. The ideafollows the solution proposed today at the Webex call
by Xavi to define a lock when two concurrent cell 
requests arrive to the node.For example, if node B requests a cell from A, 
and during this transaction node C requests a new 
cell from A, send a  Concurrent Transaction "CT_ERROR"so C knows there may still be resources available andretry later instead of giving up. Do you think this should solve the problem?
Regards,                              Diego

-- DIEGO DUJOVNE
MailScanner has detected a possible fraud attempt from "www.ingenieria.udp..cl" claiming to be www.ingenieria.udp.cl
 
[ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www..facebook.com/CDACINDIA & Twitter: @cdacindia ] 
 
------------------------------------------------------------------------------------------------------------------------------- 
[ C-DAC is on Social-Media too. Kindly follow us at: 
Facebook: https://www..facebook.com/CDACINDIA & Twitter: @cdacindia ] 

-- DIEGO DUJOVNE

 -- _______________________________________ Thomas Watteyne, PhDResearch Scientist & Innovator, InriaSr Networking Design Eng, Linear TechFounder & co-lead, UC Berkeley OpenWSNCo-chair, IETF 6TiSCH www.thomaswatteyne.com_______________________________________
-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at: 
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

-- 
_______________________________________
Thomas Watteyne, PhDResearch Scientist & Innovator, InriaSr Networking Design Eng, Linear TechFounder & co-lead, UC Berkeley OpenWSNCo-chair, IETF 6TiSCH
www.thomaswatteyne.com_______________________________________

---

From: Qin Wang <[email-masked]>
Date: Wed, 25 May 2016 14:47:12 +0000 (UTC)

Hi Diego,
I understand your concern and  your proposal to have two return codes corresponding to no enough resource and candidate cells in Lock status. But I think SF is better place to handle it. For example,  in Metadata of response message, 1-bit Flag can be used to distinguish (1) No Enough Resource and (2) Candidate Cells in Lock Status. Because SF analyze the ADD Request Message and prepare Response Message, it should not difficult for SF to provide the value of the 1-bit Flag.
What do you think?
ThanksQin 

    On Tuesday, May 24, 2016 11:29 AM, Prof. Diego Dujovne <[email-masked]> wrote:

 Xavi, all:
be the reaction, while if the error is busy due to resource (=processor/storage)
to give up the transaction.             However, for the sake of simplicity, keeping the busy error

                                        Diego

2016-05-24 10:18 GMT-04:00 Xavier Vilajosana <[email-masked]>:

Looks good to me!

Lijo,

-- DIEGO DUJOVNE

-- DIEGO DUJOVNE

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Wed, 25 May 2016 11:56:32 -0300

Qin,
      You are right. The metadata field is a good place
to use for specific details which are not available
on the errors. I agree.
Regards,

                          Diego

2016-05-25 10:47 GMT-04:00 Qin Wang <[email-masked]>:

> Hi Diego,
>
> I understand your concern and  your proposal to have two return codes
> corresponding to no enough resource and candidate cells in Lock status. But
> I think SF is better place to handle it. For example,  in Metadata of
> response message, 1-bit Flag can be used to distinguish (1) No Enough
> Resource and (2) Candidate Cells in Lock Status. Because SF analyze the ADD
> Request Message and prepare Response Message, it should not difficult for
> SF to provide the value of the 1-bit Flag.
>
> What do you think?
>
> Thanks
> Qin
>
>
> <http://www.ingenieria.udp..cl/>
> (56 2) 676 8125
>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 27 May 2016 14:44:23 +0200

All,
We have allocated 20min during the 6TiSCH interim in 77 minutes to discuss
this. I'd like to use that time as a high-bandwidth forum to exchange on
the idea and agree on the text.
Thomas

Thomas Watteyne, PhD

www.thomaswatteyne.com