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: 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 protected]> [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: <mailto:[email protected]> [email protected]] On Behalf Of Xavier Vilajosana Sent: 19 May 2016 12:03 To: Prof. Diego Dujovne Cc: Lijo Thomas; <mailto:[email protected]> [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 < <mailto:[email protected]> [email protected]>: 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 < <mailto:[email protected]> [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: <mailto:[email protected]> [email protected]] On Behalf Of Xavier Vilajosana Sent: 18 May 2016 17:52 To: Lijo Thomas Cc: <mailto:[email protected]> [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 < <mailto:[email protected]> [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: <mailto:[email protected]> [email protected]] On Behalf Of Xavier Vilajosana Sent: 14 May 2016 18:34 To: Prof. Diego Dujovne Cc: <mailto:[email protected]> [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 < <mailto:[email protected]> [email protected]>: 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 <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 _______________________________________________ 6tisch mailing list <mailto:[email protected]> [email protected] <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 ] 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> 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 <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 ] 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 <mailto:[email protected]> [email protected] <https://www.ietf.org/mailman/listinfo/6tisch> https://www.ietf.org/mailman/listinfo/6tisch -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH <http://www.thomaswatteyne.com> 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. -------------------------------------------------------------------------------------------------------------------------------
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
