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 <l...@cdac.in> 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:6tisch-boun...@ietf.org] *On Behalf Of *Xavier > Vilajosana > *Sent:* 19 May 2016 12:03 > *To:* Prof. Diego Dujovne > *Cc:* Lijo Thomas; 6tisch@ietf.org > *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 <diego.dujo...@mail.udp..cl > <diego.dujo...@mail.udp.cl>>: > > 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 <l...@cdac.in>: > > 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:6tisch-boun...@ietf.org] *On Behalf Of *Xavier > Vilajosana > *Sent:* 18 May 2016 17:52 > *To:* Lijo Thomas > *Cc:* 6tisch@ietf.org; 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 <l...@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:6tisch-boun...@ietf.org] *On Behalf Of *Xavier > Vilajosana > *Sent:* 14 May 2016 18:34 > *To:* Prof. Diego Dujovne > *Cc:* 6tisch@ietf.org > *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 <diego.dujo...@mail.udp.cl > >: > > 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 > *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 > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > 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 & 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 > 6tisch@ietf.org > 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 www.thomaswatteyne.com _______________________________________
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
