All, We have allocated 20min during the 6TiSCH interim in 77 minutes to discuss this. I'd like to use that time as a high-bandwidth forum to exchange on the idea and agree on the text. Thomas
On Wed, May 25, 2016 at 4:56 PM, Prof. Diego Dujovne < [email protected]> wrote: > Qin, > You are right. The metadata field is a good place > to use for specific details which are not available > on the errors. I agree. > Regards, > > Diego > > 2016-05-25 10:47 GMT-04:00 Qin Wang <[email protected]>: > >> Hi Diego, >> >> I understand your concern and your proposal to have two return codes >> corresponding to no enough resource and candidate cells in Lock status. But >> I think SF is better place to handle it. For example, in Metadata of >> response message, 1-bit Flag can be used to distinguish (1) No Enough >> Resource and (2) Candidate Cells in Lock Status. Because SF analyze the ADD >> Request Message and prepare Response Message, it should not difficult for >> SF to provide the value of the 1-bit Flag. >> >> What do you think? >> >> Thanks >> Qin >> >> >> On Tuesday, May 24, 2016 11:29 AM, Prof. Diego Dujovne < >> [email protected]> wrote: >> >> >> Xavi, all: >> Going back on what you proposed and the revised >> text, the ony difference I see between a specific error on concurrent >> transactions and the busy error, is the possibility to choose between >> different retry periods and the number of retries by the SF: >> If a child desperately needs new cells, and the only problem >> is concurrency, a short retry period and a high number of retries may >> be the reaction, while if the error is busy due to resource >> (=processor/storage) >> constraints, then the reaction would be a longer retry period, or even >> to give up the transaction. >> However, for the sake of simplicity, keeping the busy error >> response does the job in a more generic way. >> Regards, >> >> Diego >> >> >> 2016-05-24 10:18 GMT-04:00 Xavier Vilajosana < >> [email protected]>: >> >> Looks good to me! >> >> === >> 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 mechanism, as decided by the Scheduling Function. >> === >> >> X >> >> 2016-05-24 13:39 GMT+02:00 Thomas Watteyne <[email protected]>: >> >> Lijo, >> >> Looks good to me. A tiny typo: >> >> === >> 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 mechanism, as decided by the Scheduling Function. >> === >> >> Any further comments/suggestions? >> >> Thomas >> >> On Tue, May 24, 2016 at 8:16 AM, Lijo Thomas <[email protected]> wrote: >> >> 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 <[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:[email protected]] *On Behalf Of *Xavier >> Vilajosana >> *Sent:* 19 May 2016 12:03 >> *To:* Prof. Diego Dujovne >> *Cc:* Lijo Thomas; [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 < >> [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 <[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:[email protected]] *On Behalf Of *Xavier >> Vilajosana >> *Sent:* 18 May 2016 17:52 >> *To:* Lijo Thomas >> *Cc:* [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 <[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:[email protected]] *On Behalf Of *Xavier >> Vilajosana >> *Sent:* 14 May 2016 18:34 >> *To:* Prof. Diego Dujovne >> *Cc:* [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 <[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 >> *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 >> [email protected] >> 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 >> 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 >> [email protected] >> 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 >> _______________________________________ >> >> ------------------------------------------------------------------------------------------------------------------------------- >> >> [ 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. >> ------------------------------------------------------------------------------------------------------------------------------- >> >> >> >> >> >> -- >> _______________________________________ >> >> 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 >> _______________________________________ >> >> >> >> >> >> -- >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> > > > -- > 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 > -- _______________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/6tisch
