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]>:
>
> 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 & 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
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
