Dear Maria and Diego, Thanks a lot for pointing the relevance of a sequence number for a transaction (point 2) A node may accept a new transaction while another enqueued previous reply has not yet been transmitted. As I noticed in the openwsn implementation, this situation is very common (several inquirers transmit a request in parallel to the same node).
Best regards, Fabrice Théoleyre > Diego, > Thanks for raising this discussion. About: > > 1) If we assume the cells should belong to a given container, for > instance a chunk (owned by a parent node), it makes sense it is always the > parent to suggest the list of candidate cells. This implies we need to > re-define better the transaction/negotiation between two neighbors: > a) Upstream traffic. We will have a 3phases negotiation: the child asks > for more cells, the parent suggests the list of cells, the child checks the > list and pick the ones suitable. > b) Downstream traffic: 2 phases - the parent asks and proposes > the list of cells, the child checks the list and picks the ones suitable. > > 2) I remember we discussed about sequence number for tracking the > transaction already. But while updating the draft, we did not > include/consider it. Of course, we have to take into account overhead > produced and thus, scalability of the solution. > > Best Regards, > Maria Rita > <> > From: 6tisch [mailto:[email protected]] On Behalf Of Prof. Diego Dujovne > Sent: Friday, November 6, 2015 7:31 PM > To: [email protected] > Subject: [6tisch] Comments on the 6top-sublayer and 6top-sf0 drafts > > Dear all, > Regarding the discussion on the 6top-sublayer and the > 6top-sf0 drafts, I would like to point out two items: > > - First, If there is a preference for the parent's > schedule over the child, I think the transaction should be started > always from the parent side, but requested (maybe) from the child node. > The problem I see there is that we must define a cell direction indicator > to allocate the cells. Until now, we were managing allocation in a > neighbour-to-neighbour basis, so the one requesting allocation defined > the direction, as Thomas pointed out. > > Example: Given two nodes, A and B, neighbours: > > If A starts an allocation request towards B, then, it is expected that A wants > to send traffic to B, so the direction is implicit. > > Now, If A is the child and B the parent, A requires cells in the A->B > direction: > A asks B to allocate cells, in the A->B direction; then B starts an allocation > request to A asking for cells in the A->B direction. > > If we do not specify the direction, then, the cell will be allocated in the > opposite > direction. (B->A). > > One further item: I assume that we must always use RPL for 6tisch, and that > the RPL DODAG is already formed before SF0 starts sending requests to 6top. > > - Second: I agree with Pascal on adding a sequence number to keep > track of transactions. This increases reliability on top of the already > established non-concurrent transactions+timeout philosophy. > I'm only worried about the overhead of this approach (longer > packet and transaction sequence number storage and verification) > > What do you think on the former comments? > > Thank you. > Regards, > > Diego > > -- > DIEGO DUJOVNE > Académico Escuela de Ingeniería en Informática y Telecomunicaciones > Facultad de Ingeniería UDP > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
