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 > www.ingenieria.udp.cl > (56 2) 676 8125 > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
