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 & 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
