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 <qinwang6...@yahoo.com>:
> 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 <
> diego.dujo...@mail.udp.cl> 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 <
> xvilajos...@eecs.berkeley.edu>:
>
> 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 <thomas.watte...@inria.fr>:
>
> 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 <l...@cdac.in> 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:6tisch-boun...@ietf.org] *On Behalf Of *Thomas
> Watteyne
> *Sent:* 23 May 2016 18:03
> *To:* Lijo Thomas
> *Cc:* 6tisch@ietf.org; 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 <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 <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
> <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
> _______________________________________
>
> -------------------------------------------------------------------------------------------------------------------------------
>
> [ 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
> 6tisch@ietf.org
> 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
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
