Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation
Hi Pascal, This scheme sounds okay ,since it removes the need for 3rd transaction (ACK) I feel the periodic sending of bit pattern is not required. Thanks & Regards, Lijo Thomas From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: 10 March 2016 13:45 To: Qin Wang Cc: Lijo Thomas; 6tisch@ietf.org; Prof. Diego Dujovne Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation Hello Qin A chunk is like heap in malloc, a trick for allocation purpose by the parent to get and defend many cells in one shot. It is more link a “super bundle” than a chunk, since it is a bundle of cells with some slots active and some not, depending on the bit mask that the parent indicates. Cheers, Pascal From: Qin Wang [ <mailto:qinwang6...@yahoo.com> mailto:qinwang6...@yahoo.com] Sent: mercredi 9 mars 2016 21:17 To: Pascal Thubert (pthubert) < <mailto:pthub...@cisco.com> pthub...@cisco.com> Cc: Lijo Thomas < <mailto:l...@cdac.in> l...@cdac.in>; Prof. Diego Dujovne < <mailto:diego.dujo...@mail.udp.cl> diego.dujo...@mail.udp.cl>; <mailto:6tisch@ietf.org> 6tisch@ietf.org Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation Pascal, I think the scheme works. BTW, the function of step1 is assigning a chunk to a child, right? In addition, I think that the bitmap can be carried in the Container (or called as Metadata) + CellList field, which are coded by specific SF. What do you think? Thanks Qin On Wednesday, March 9, 2016 12:33 PM, Pascal Thubert (pthubert) < <mailto:pthub...@cisco.com> pthub...@cisco.com> wrote: With this method, Qin: Step 1 is performed once and that’s probably it for life unless the child needs more than 16 cells; Step 2 is really the add/delete flow. Child says “add 3” and the parent responds with the bitmap with 3 more bits set. If the child does not see the response it may say “add 0” and get the bitmap from the parent perspective, with either no additional bit if the request was lost or the expected 3 more bits if the response was lost. This approach removes the need for transactionality. The parent may opportunistically / periodically resend the bitmap to the child just to make sure the child has the correct view. Cheers, Pascal From: Qin Wang [ <mailto:qinwang6...@yahoo.com> mailto:qinwang6...@yahoo.com] Sent: mercredi 9 mars 2016 17:30 To: Pascal Thubert (pthubert) < <mailto:pthub...@cisco.com> pthub...@cisco.com> Cc: Lijo Thomas < <mailto:l...@cdac.in> l...@cdac.in>; Prof. Diego Dujovne < <mailto:diego.dujo...@mail.udp.cl> diego.dujo...@mail.udp.cl>; <mailto:6tisch@ietf.org> 6tisch@ietf.org Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation Hi Pascal, I want confirm what I understood. (1) Both step1 and step2 are extra message besides ADD/DELETE message exchange (2) Because the step1 and step2, Child will know which cells it can use. Then, when the child wants more cells, the child selects the cells from those set as UNUSED in the bitmap, as candidates, and send ADD request to parent. And the parent will send Response to confirm. That is 2-stages, instead of 3-stages message exchange. Thanks Qin On Wednesday, March 9, 2016 3:05 AM, Pascal Thubert (pthubert) < <mailto:pthub...@cisco.com> pthub...@cisco.com> wrote: Hello Qin: Please consider the message by Tero. The ack is Mac-layer before upper layer processing and does not guarantee success in the stack. What we'd really want is suppress the MAC layer ack but not the 6P response. Another angle (for the sake of making sure we left no stone unturned). If we think transactionality is too difficult to achieve and that parent/child may lose sync: it is possible to avoid the issues with transactionality by using a bitmap to represent cells like LoRa does with frequencies. Step 1 the parent provides a list of cells (say 16) that it may allocate to that child in the future. The list may differ per child and may overlap with other children to enable to parent to temporarily give a cell to one child or another. Step 2 (runtime) the parent sends the bitmap of the cells, bit set if the cell is use child to parent. If this is sent regularly like a frame relay full status, things will eventually sync. What do you think? Pascal Le 8 mars 2016 à 22:34, Qin Wang < <mailto:qinwang6...@yahoo.com> qinwang6...@yahoo.com> a écrit : Hi Diego, I also have question regarding to the third message, i.e. Child acknowledge. In this case, the Child must accept the selected cells in the Parent's message if it received the message. Right? In another word, if the Parent knows the Child has received the message correctly, the Parent can be sure that the selected cells will be added/deleted into/fro
Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation
Hello Qin A chunk is like heap in malloc, a trick for allocation purpose by the parent to get and defend many cells in one shot. It is more link a “super bundle” than a chunk, since it is a bundle of cells with some slots active and some not, depending on the bit mask that the parent indicates. Cheers, Pascal From: Qin Wang [mailto:qinwang6...@yahoo.com] Sent: mercredi 9 mars 2016 21:17 To: Pascal Thubert (pthubert) <pthub...@cisco.com> Cc: Lijo Thomas <l...@cdac.in>; Prof. Diego Dujovne <diego.dujo...@mail.udp.cl>; 6tisch@ietf.org Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation Pascal, I think the scheme works. BTW, the function of step1 is assigning a chunk to a child, right? In addition, I think that the bitmap can be carried in the Container (or called as Metadata) + CellList field, which are coded by specific SF. What do you think? Thanks Qin On Wednesday, March 9, 2016 12:33 PM, Pascal Thubert (pthubert) <pthub...@cisco.com<mailto:pthub...@cisco.com>> wrote: With this method, Qin: Step 1 is performed once and that’s probably it for life unless the child needs more than 16 cells; Step 2 is really the add/delete flow. Child says “add 3” and the parent responds with the bitmap with 3 more bits set. If the child does not see the response it may say “add 0” and get the bitmap from the parent perspective, with either no additional bit if the request was lost or the expected 3 more bits if the response was lost. This approach removes the need for transactionality. The parent may opportunistically / periodically resend the bitmap to the child just to make sure the child has the correct view. Cheers, Pascal From: Qin Wang [mailto:qinwang6...@yahoo.com] Sent: mercredi 9 mars 2016 17:30 To: Pascal Thubert (pthubert) <pthub...@cisco.com<mailto:pthub...@cisco.com>> Cc: Lijo Thomas <l...@cdac.in<mailto:l...@cdac.in>>; Prof. Diego Dujovne <diego.dujo...@mail.udp.cl<mailto:diego.dujo...@mail.udp.cl>>; 6tisch@ietf.org<mailto:6tisch@ietf.org> Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation Hi Pascal, I want confirm what I understood. (1) Both step1 and step2 are extra message besides ADD/DELETE message exchange (2) Because the step1 and step2, Child will know which cells it can use. Then, when the child wants more cells, the child selects the cells from those set as UNUSED in the bitmap, as candidates, and send ADD request to parent. And the parent will send Response to confirm. That is 2-stages, instead of 3-stages message exchange. Thanks Qin On Wednesday, March 9, 2016 3:05 AM, Pascal Thubert (pthubert) <pthub...@cisco.com<mailto:pthub...@cisco.com>> wrote: Hello Qin: Please consider the message by Tero. The ack is Mac-layer before upper layer processing and does not guarantee success in the stack. What we'd really want is suppress the MAC layer ack but not the 6P response. Another angle (for the sake of making sure we left no stone unturned). If we think transactionality is too difficult to achieve and that parent/child may lose sync: it is possible to avoid the issues with transactionality by using a bitmap to represent cells like LoRa does with frequencies. Step 1 the parent provides a list of cells (say 16) that it may allocate to that child in the future. The list may differ per child and may overlap with other children to enable to parent to temporarily give a cell to one child or another. Step 2 (runtime) the parent sends the bitmap of the cells, bit set if the cell is use child to parent. If this is sent regularly like a frame relay full status, things will eventually sync. What do you think? Pascal Le 8 mars 2016 à 22:34, Qin Wang <qinwang6...@yahoo.com<mailto:qinwang6...@yahoo.com>> a écrit : Hi Diego, I also have question regarding to the third message, i.e. Child acknowledge. In this case, the Child must accept the selected cells in the Parent's message if it received the message. Right? In another word, if the Parent knows the Child has received the message correctly, the Parent can be sure that the selected cells will be added/deleted into/from the Child's schedule. Since the MAC layer ACK can tell Parent the Child has received its message correctly, I think there is no need for the Child to send back the 6P layer Acknowledgement. Do I miss something? Thanks Qin On Friday, March 4, 2016 7:51 AM, Lijo Thomas <l...@cdac.in<mailto:l...@cdac.in>> wrote: Hi Diego, Do we really require 3 transactions for 6P operations as mentioned. The second transaction from the parent contains all the required information for the task. In case the 2nd packet is lost, the parent will schedule a RX link which will be unutilized for the time being and can be reallocated depending on the scheduling function. But if the 3rd transaction is lost, the
Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation
With this method, Qin: Step 1 is performed once and that’s probably it for life unless the child needs more than 16 cells; Step 2 is really the add/delete flow. Child says “add 3” and the parent responds with the bitmap with 3 more bits set. If the child does not see the response it may say “add 0” and get the bitmap from the parent perspective, with either no additional bit if the request was lost or the expected 3 more bits if the response was lost. This approach removes the need for transactionality. The parent may opportunistically / periodically resend the bitmap to the child just to make sure the child has the correct view. Cheers, Pascal From: Qin Wang [mailto:qinwang6...@yahoo.com] Sent: mercredi 9 mars 2016 17:30 To: Pascal Thubert (pthubert) <pthub...@cisco.com> Cc: Lijo Thomas <l...@cdac.in>; Prof. Diego Dujovne <diego.dujo...@mail.udp.cl>; 6tisch@ietf.org Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation Hi Pascal, I want confirm what I understood. (1) Both step1 and step2 are extra message besides ADD/DELETE message exchange (2) Because the step1 and step2, Child will know which cells it can use. Then, when the child wants more cells, the child selects the cells from those set as UNUSED in the bitmap, as candidates, and send ADD request to parent. And the parent will send Response to confirm. That is 2-stages, instead of 3-stages message exchange. Thanks Qin On Wednesday, March 9, 2016 3:05 AM, Pascal Thubert (pthubert) <pthub...@cisco.com<mailto:pthub...@cisco.com>> wrote: Hello Qin: Please consider the message by Tero. The ack is Mac-layer before upper layer processing and does not guarantee success in the stack. What we'd really want is suppress the MAC layer ack but not the 6P response. Another angle (for the sake of making sure we left no stone unturned). If we think transactionality is too difficult to achieve and that parent/child may lose sync: it is possible to avoid the issues with transactionality by using a bitmap to represent cells like LoRa does with frequencies. Step 1 the parent provides a list of cells (say 16) that it may allocate to that child in the future. The list may differ per child and may overlap with other children to enable to parent to temporarily give a cell to one child or another. Step 2 (runtime) the parent sends the bitmap of the cells, bit set if the cell is use child to parent. If this is sent regularly like a frame relay full status, things will eventually sync. What do you think? Pascal Le 8 mars 2016 à 22:34, Qin Wang <qinwang6...@yahoo.com<mailto:qinwang6...@yahoo.com>> a écrit : Hi Diego, I also have question regarding to the third message, i.e. Child acknowledge. In this case, the Child must accept the selected cells in the Parent's message if it received the message. Right? In another word, if the Parent knows the Child has received the message correctly, the Parent can be sure that the selected cells will be added/deleted into/from the Child's schedule. Since the MAC layer ACK can tell Parent the Child has received its message correctly, I think there is no need for the Child to send back the 6P layer Acknowledgement. Do I miss something? Thanks Qin On Friday, March 4, 2016 7:51 AM, Lijo Thomas <l...@cdac.in<mailto:l...@cdac.in>> wrote: Hi Diego, Do we really require 3 transactions for 6P operations as mentioned. The second transaction from the parent contains all the required information for the task. In case the 2nd packet is lost, the parent will schedule a RX link which will be unutilized for the time being and can be reallocated depending on the scheduling function. But if the 3rd transaction is lost, the client will allocate the TX link and will start transmitting packets. So can we avoid the ACK packet(3rd transaction) from the client, or is there any added benefit. Thanks & Regards, Lijo Thomas From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Prof. Diego Dujovne Sent: 03 March 2016 21:11 To: 6tisch@ietf.org<mailto:6tisch@ietf.org> Subject: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation Dear all, Given that there is parent preference in cell selection, a child-initiated transaction triggers a three-step exchange: 1- Child sends request to Parent with whitelist/blacklist of slotoffsets 2- Parent selects cells 3- Child acknowledges and finishes the transaction The main idea is to enable an optional Piggybacking of the IE on a data packet to reduce the number of transmitted packets, but there are latency concerns when the (data) traffic is low. Is it worth to enable this option given the added complexity? Regards, Diego Dujovne -- DIEGO DUJOVNE Académico Escuela de Ingeniería en Informática y Telecomunicaciones Facultad de Ingeniería UDP www.
Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation
Hi Diego, Do we really require 3 transactions for 6P operations as mentioned. The second transaction from the parent contains all the required information for the task. In case the 2nd packet is lost, the parent will schedule a RX link which will be unutilized for the time being and can be reallocated depending on the scheduling function. But if the 3rd transaction is lost, the client will allocate the TX link and will start transmitting packets. So can we avoid the ACK packet(3rd transaction) from the client, or is there any added benefit. Thanks & Regards, Lijo Thomas From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Prof. Diego Dujovne Sent: 03 March 2016 21:11 To: 6tisch@ietf.org Subject: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation Dear all, Given that there is parent preference in cell selection, a child-initiated transaction triggers a three-step exchange: 1- Child sends request to Parent with whitelist/blacklist of slotoffsets 2- Parent selects cells 3- Child acknowledges and finishes the transaction The main idea is to enable an optional Piggybacking of the IE on a data packet to reduce the number of transmitted packets, but there are latency concerns when the (data) traffic is low. Is it worth to enable this option given the added complexity? Regards, Diego Dujovne -- 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 --- [ 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. --- ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
[6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation
Dear all, Given that there is parent preference in cell selection, a child-initiated transaction triggers a three-step exchange: 1- Child sends request to Parent with whitelist/blacklist of slotoffsets 2- Parent selects cells 3- Child acknowledges and finishes the transaction The main idea is to enable an optional Piggybacking of the IE on a data packet to reduce the number of transmitted packets, but there are latency concerns when the (data) traffic is low. Is it worth to enable this option given the added complexity? Regards, Diego Dujovne -- 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 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
