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
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.
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
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.
Dear all,
Please, let me forward the Invitation Letter that has been recently sent out
from ETSI for the upcoming 6TiSCH/6lo Plugtests that will be held in Berlin
from 15th to 17th July. In there, you will find the 6TiSCH/6lo Plugtests
website where more details can be found.
Also,
