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 protected]> wrote:
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 protected]>:
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 protected]>:
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 protected]> 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 protected]] On Behalf Of Thomas Watteyne
Sent: 23 May 2016 18:03
To: Lijo Thomas
Cc: [email protected]; 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 protected]> 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 protected]] On Behalf Of Xavier Vilajosana
Sent: 19 May 2016 12:03
To: Prof. Diego Dujovne
Cc: Lijo Thomas; [email protected]
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 protected]>:
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 protected]>:
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 protected]] On Behalf Of Xavier Vilajosana
Sent: 18 May 2016 17:52
To: Lijo Thomas
Cc: [email protected]; 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 <[email protected]>:
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 protected]] On Behalf Of Xavier Vilajosana
Sent: 14 May 2016 18:34
To: Prof. Diego Dujovne
Cc: [email protected]
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 protected]>:
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
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
MailScanner has detected a possible fraud attempt from "www.ingenieria.udp..cl"
claiming to be www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tisch mailing list
[email protected]
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.
-------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------
[ 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.
-------------------------------------------------------------------------------------------------------------------------------
-- 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
-------------------------------------------------------------------------------------------------------------------------------
[ 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.
-------------------------------------------------------------------------------------------------------------------------------
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
-- _______________________________________ 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 ]
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.
-------------------------------------------------------------------------------------------------------------------------------
--
_______________________________________
Thomas Watteyne, PhDResearch Scientist & Innovator, InriaSr Networking Design
Eng, Linear TechFounder & co-lead, UC Berkeley OpenWSNCo-chair, IETF 6TiSCH
www.thomaswatteyne.com_______________________________________
--
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
