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
