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>: > 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 & 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 >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
