Subject: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 3 Mar 2016 12:41:22 -0300

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

---

From: "Lijo Thomas" <[email-masked]>
Date: Fri, 4 Mar 2016 18:21:43 +0530

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:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: 03 March 2016 21:11
To: [email-masked]
Subject: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation

Dear all,

exchange:

2- Parent selects cells

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.
-------------------------------------------------------------------------------------------------------------------------------

---

From: Qin Wang <[email-masked]>
Date: Tue, 8 Mar 2016 21:32:54 +0000 (UTC)

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?
ThanksQin 

    On Friday, March 4, 2016 7:51 AM, Lijo Thomas <[email-masked]> wrote:

 #yiv9292455179 #yiv9292455179 -- _filtered #yiv9292455179 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv9292455179 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv9292455179 {panose-1:2 11 6 3 2 2 2 2 2 4;} _filtered #yiv9292455179 {panose-1:2 5 6 4 5 5 5 2 2 4;}#yiv9292455179 #yiv9292455179 p.yiv9292455179MsoNormal, #yiv9292455179 li.yiv9292455179MsoNormal, #yiv9292455179 div.yiv9292455179MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;}#yiv9292455179 a:link, #yiv9292455179 span.yiv9292455179MsoHyperlink {color:blue;text-decoration:underline;}#yiv9292455179 a:visited, #yiv9292455179 span.yiv9292455179MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv9292455179 span.yiv9292455179EmailStyle17 {color:#1F497D;}#yiv9292455179 span.yiv9292455179EmailStyle18 {color:#833C0B;}#yiv9292455179 .yiv9292455179MsoChpDefault {font-size:10.0pt;} _filtered #yiv9292455179 {margin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv9292455179 div.yiv9292455179WordSection1 {}#yiv9292455179 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:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: 03 March 2016 21:11
To: [email-masked]
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-stepexchange:1- Child sends request to Parent with whitelist/blacklist of slotoffsets2- Parent selects cells3- Child acknowledges and finishes the transactionThe main idea is to enable an optional Piggybacking of the IE on adata packet to reduce the number of transmitted packets, but thereare 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
-------------------------------------------------------------------------------------------------------------------------------
[ 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
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Mar 2016 08:05:07 +0000

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 <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Diego,

Do I miss something?

Thanks
Qin

On Friday, March 4, 2016 7:51 AM, Lijo Thomas <[email-masked]<mailto:[email-masked]>> wrote:

Hi Diego,

Thanks & Regards,
Lijo Thomas

From: 6tisch [mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: 03 March 2016 21:11
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation

Dear all,

--
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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Qin Wang <[email-masked]>
Date: Wed, 9 Mar 2016 16:29:37 +0000 (UTC)

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.
ThanksQin

    On Wednesday, March 9, 2016 3:05 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:

 Hello Qin:

Pascal
Le 8 mars 2016 à 22:34, Qin Wang <[email-masked]> a écrit :

Hi Diego,

#yiv8088234616 -- filtered {panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv8088234616 filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv8088234616 filtered {panose-1:2 11 6 3 2 2 2 2 2 4;}#yiv8088234616 filtered {panose-1:2 5 6 4 5 5 5 2 2 4;}#yiv8088234616 p.yiv8088234616MsoNormal, #yiv8088234616 li.yiv8088234616MsoNormal, #yiv8088234616 div.yiv8088234616MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;}#yiv8088234616 a:link, #yiv8088234616 span.yiv8088234616MsoHyperlink {color:blue;text-decoration:underline;}#yiv8088234616 a:visited, #yiv8088234616 span.yiv8088234616MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv8088234616 span.yiv8088234616EmailStyle17 {color:#1F497D;}#yiv8088234616 span.yiv8088234616EmailStyle18 {color:#833C0B;}#yiv8088234616 .yiv8088234616MsoChpDefault {font-size:10.0pt;}#yiv8088234616 filtered {margin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv8088234616 div.yiv8088234616WordSection1 {}#yiv8088234616 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:[email-masked]]On Behalf Of Prof. Diego Dujovne

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Mar 2016 17:33:18 +0000

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:[email-masked]]
Sent: mercredi 9 mars 2016 17:30
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Lijo Thomas <[email-masked]>; Prof. Diego Dujovne <[email-masked]>; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Qin:

What do you think?

Pascal

Do I miss something?

Thanks
Qin

Hi Diego,

Thanks & Regards,
Lijo Thomas

Dear all,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Mar 2016 08:14:56 +0000

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

Sent: mercredi 9 mars 2016 21:17

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) <[email-masked]<mailto:[email-masked]>> wrote:

With this method, Qin:

Cheers,

Pascal

From: Qin Wang [mailto:[email-masked]]
Sent: mercredi 9 mars 2016 17:30
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: Lijo Thomas <[email-masked]<mailto:[email-masked]>>; Prof. Diego Dujovne <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation

Hi Pascal,

Thanks
Qin

Hello Qin:

What do you think?

Pascal

Do I miss something?

Thanks
Qin

Hi Diego,

Thanks & Regards,
Lijo Thomas

Dear all,

---

From: "Lijo Thomas" <[email-masked]>
Date: Thu, 10 Mar 2016 16:47:28 +0530

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:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 10 March 2016 13:45
To: Qin Wang
Cc: Lijo Thomas; [email-masked]; Prof. Diego Dujovne
Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation
 
Hello Qin

 
Cheers,
 
Pascal
 
From: Qin Wang [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: mercredi 9 mars 2016 21:17
To: Pascal Thubert (pthubert) < <mailto:[email-masked]> [email-masked]>
Cc: Lijo Thomas < <mailto:[email-masked]> [email-masked]>; Prof. Diego Dujovne < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation
 
Pascal,

 
What do you think?
 
Thanks
Qin 
 
On Wednesday, March 9, 2016 12:33 PM, Pascal Thubert (pthubert) < <mailto:[email-masked]> [email-masked]> wrote:
 
With this method, Qin:

 
 
Cheers,
 
Pascal
 
From: Qin Wang [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: mercredi 9 mars 2016 17:30
To: Pascal Thubert (pthubert) < <mailto:[email-masked]> [email-masked]>
Cc: Lijo Thomas < <mailto:[email-masked]> [email-masked]>; Prof. Diego Dujovne < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation
 
Hi Pascal,

Thanks
Qin

On Wednesday, March 9, 2016 3:05 AM, Pascal Thubert (pthubert) < <mailto:[email-masked]> [email-masked]> wrote:
 
Hello Qin:

 

 

What do you think?
 
Pascal

Le 8 mars 2016 à 22:34, Qin Wang < <mailto:[email-masked]> [email-masked]> a écrit :
Hi Diego,

 
Do I miss something?
 
Thanks
Qin
 
On Friday, March 4, 2016 7:51 AM, Lijo Thomas < <mailto:[email-masked]> [email-masked]> wrote:
 
Hi Diego,

 

Thanks & Regards,
Lijo Thomas 

From: 6tisch [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: 03 March 2016 21:11
To:  <mailto:[email-masked]> [email-masked]
Subject: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation
 
Dear all,

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
 <http://www.ingenieria.udp.cl/> 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> https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] 

_______________________________________________
6tisch mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/6tisch> https://www.ietf.org/mailman/listinfo/6tisch
 
_______________________________________________
6tisch mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/6tisch> https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Mar 2016 14:45:02 +0000

Hi Lijo

The usual way of doing this is to send it upon a change like parent or child reboot, and upon reconnection. Then you send it again with an exponential Back off.

The alternate is to be transactional and be able to resync, all of which is easier with the bitmap than it is in the current 6p protocol as I illustrated with the "add 0".

I agree that both ways are valid alternatives to the current draft. It is up to this group to refine was suits best 6 TiSCH nodes.

Regards,

Pascal

Le 10 mars 2016 à 12:16, Lijo Thomas <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal,

Thanks & Regards,
Lijo Thomas

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 10 March 2016 13:45
To: Qin Wang
Cc: Lijo Thomas; [email-masked]<mailto:[email-masked]>; Prof. Diego Dujovne
Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation

Hello Qin

Cheers,

Pascal

Pascal,

What do you think?

Thanks
Qin

With this method, Qin:

Cheers,

Pascal

Hi Pascal,

Thanks
Qin

Hello Qin:

What do you think?

Pascal

Do I miss something?

Thanks
Qin

Hi Diego,

Thanks & Regards,
Lijo Thomas

Dear all,

---

From: "Lijo Thomas" <[email-masked]>
Date: Fri, 11 Mar 2016 15:25:34 +0530

Hi Pascal,

I agree with you. 

“add 0” will ease the resync and the bitmap method will be simpler and save
bytes during 6P transaction.

Consider the case of a network  depicted below,

P1 

|

P2

|

C1

When P2 sends a cell request to P1,  P1 is unaware of the communication
slots P2 is having with its child nodes, say C1.

So do we need to send the preferable bitmaps of the child to the parent with
the add cell request.

Thanks & Regards,

Lijo Thomas 

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert
(pthubert)
Sent: 10 March 2016 20:15
To: Lijo Thomas
Cc: Prof. Diego Dujovne; [email-masked]
Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE
confirmation

Hi Lijo

The usual way of doing this is to send it upon a change like parent or child
reboot, and upon reconnection. Then you send it again with an exponential
Back off. 

The alternate is to be transactional and be able to resync, all of which is
easier with the bitmap than it is in the current 6p protocol as I
illustrated with the "add 0".

I agree that both ways are valid alternatives to the current draft. It is up
to this group to refine was suits best 6 TiSCH nodes.

Regards, 

Pascal

Le 10 mars 2016 à 12:16, Lijo Thomas <[email-masked] <mailto:[email-masked]> > a
écrit :

Hi Pascal,

This scheme sounds okay ,since it removes the need for 3rd   transaction
(ACK)

Thanks & Regards,

Lijo Thomas 

From: 6tisch [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 10 March 2016 13:45
To: Qin Wang
Cc: Lijo Thomas;  <mailto:[email-masked]> [email-masked]; 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:[email-masked]>
mailto:[email-masked]] 
Sent: mercredi 9 mars 2016 21:17
To: Pascal Thubert (pthubert) < <mailto:[email-masked]>
[email-masked]>
Cc: Lijo Thomas < <mailto:[email-masked]> [email-masked]>; Prof. Diego Dujovne <
<mailto:diego.dujovne@mail..udp.cl> [email-masked]>;
<mailto:[email-masked]> [email-masked]
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:[email-masked]> [email-masked]> 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:[email-masked]>
mailto:[email-masked]] 
Sent: mercredi 9 mars 2016 17:30
To: Pascal Thubert (pthubert) < <mailto:[email-masked]>
[email-masked]>
Cc: Lijo Thomas < <mailto:[email-masked]> [email-masked]>; Prof. Diego Dujovne <
<mailto:diego.dujovne@mail..udp.cl> [email-masked]>;
<mailto:[email-masked]> [email-masked]
Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE
confirmation

Hi Pascal,

(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:[email-masked]> [email-masked]> wrote:

Hello Qin:

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..

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:[email-masked]>
[email-masked]> a écrit :

Hi Diego,

 

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 < <mailto:[email-masked]>
[email-masked]> wrote:

Hi Diego,

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:[email-masked]>
mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: 03 March 2016 21:11
To:  <mailto:[email-masked]> [email-masked]
Subject: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE
confirmation

Dear all,

exchange:

2- Parent selects cells

Regards,

                                Diego Dujovne

-- 

DIEGO DUJOVNE

----------------------------------------------------------------------------
--------------------------------------------------- 
[ C-DAC is on Social-Media too. Kindly follow us at: 
Facebook:  <https://www.facebook.com/CDACINDIA>
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
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/6tisch>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/6tisch>
https://www.ietf.org/mailman/listinfo/6tisch

----------------------------------------------------------------------------
--------------------------------------------------- 
[ 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. 
----------------------------------------------------------------------------
---------------------------------------------------

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Mar 2016 10:31:48 +0000

I agree with you, Lijo.

Unsure if the group wants to use bitmaps but at the end of the day, it is a compression mechanism for the 6P exchanges.

Best regards,

Pascal

From: Lijo Thomas [mailto:[email-masked]]
Sent: vendredi 11 mars 2016 10:56
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: 'Prof. Diego Dujovne' <[email-masked]>; [email-masked]
Subject: RE: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation

Hi Pascal,

I agree with you.

"add 0" will ease the resync and the bitmap method will be simpler and save bytes during 6P transaction.

When P2 sends a cell request to P1,  P1 is unaware of the communication slots P2 is having with its child nodes, say C1.

So do we need to send the preferable bitmaps of the child to the parent with the add cell request.

Thanks & Regards,
Lijo Thomas

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 10 March 2016 20:15
To: Lijo Thomas
Cc: Prof. Diego Dujovne; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation

Hi Lijo

Regards,

Pascal

Thanks & Regards,
Lijo Thomas

Hello Qin

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

Cc: Lijo Thomas <[email-masked]<mailto:[email-masked]>>; Prof. Diego Dujovne <[email-masked]<mailto:diego.dujovne@mail..udp.cl>>; [email-masked]<mailto:[email-masked]>

Pascal,

What do you think?

Thanks
Qin

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.

Cheers,

Pascal

Cc: Lijo Thomas <[email-masked]<mailto:[email-masked]>>; Prof. Diego Dujovne <[email-masked]<mailto:diego.dujovne@mail..udp.cl>>; [email-masked]<mailto:[email-masked]>

Hi Pascal,

Thanks
Qin

Hello Qin:

What we'd really want is suppress the MAC layer ack but not the 6P response..

What do you think?

Pascal

Do I miss something?

Thanks
Qin

Hi Diego,

Thanks & Regards,
Lijo Thomas

Dear all,