Hello Qin: The parent owns a chunk but the child does not know what chunk that is and which cells in that chunk are free. The best the child could propose is a series of time offsets. The reason it would do that is to avoid that the parent proposes cells that collision with times when the child talks to other nodes, either alt parent or its own children. In any fashion we need the child to accept the cells so there needs to be a response. What we could do to save is piggyback the IE for the initial request by the child with a data packet.
Cheers, Pascal From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Qin Wang Sent: mardi 10 novembre 2015 16:42 To: Maria Rita PALATTELLA <maria-rita.palatte...@uni.lu>; Prof. Diego Dujovne <diego.dujo...@mail.udp.cl>; 6tisch@ietf.org Subject: Re: [6tisch] Comments on the 6top-sublayer and 6top-sf0 drafts Hi Maria Rita and all, For support RPL structure of parent & children, I agree to think upstream and downstream resource reservation separately. But, I'm not sure if we should use 3-phase protocol for upstream resource reservation, because that means 1/3 communication cost will be added for one transaction. Maybe we can implement the upstream resource reservation in this way. (1) The Child sends a Request message to its parent to require adding TX cells, including NumCells, but without candidate CellList. Then, the parent choose the cells for this Request without any constraint, and send back Response message to the Child including the selected CellList; Or (2) The Child sends a Request message to its parent to require TX cells, including NumCells and candidate CellList, but the CellList is just information instead of requirement. Then the parent choose cells for this Request considering the CellList or ignoring the CellList, and send back Response message to the Child. The basic idea is the rule of processing Request message involves the position of nodes, i.e. parent or child. A problem could be the new selected cells may conflict with the cells already used by the child with its children. I think the problem can be solved by using un-overlapped Chunk in the neighborhood. What do you think? Thanks Qin On Monday, November 9, 2015 7:33 AM, Maria Rita PALATTELLA <maria-rita.palatte...@uni.lu<mailto:maria-rita.palatte...@uni.lu>> wrote: 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:6tisch-boun...@ietf.org] On Behalf Of Prof. Diego Dujovne Sent: Friday, November 6, 2015 7:31 PM To: 6tisch@ietf.org<mailto:6tisch@ietf.org> 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 6tisch@ietf.org<mailto:6tisch@ietf.org> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
