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 <mailto: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 <mailto: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 <mailto:6tisch-boun...@ietf.org> ] On Behalf Of Xavier Vilajosana Sent: 18 May 2016 17:52 To: Lijo Thomas Cc: 6tisch@ietf.org <mailto: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 <mailto: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 <mailto:6tisch-boun...@ietf.org> ] On Behalf Of Xavier Vilajosana Sent: 14 May 2016 18:34 To: Prof. Diego Dujovne Cc: 6tisch@ietf.org <mailto: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 <mailto: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 <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 6tisch@ietf.org <mailto: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 <http://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
