Subject: [6tisch] Comments on the 6top-sublayer and 6top-sf0 drafts

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 6 Nov 2015 15:31:28 -0300

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
(56 2) 676 8125

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Mon, 9 Nov 2015 12:33:00 +0000

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-masked]] On Behalf Of Prof. Diego Dujovne
Sent: Friday, November 6, 2015 7:31 PM
To: [email-masked]
Subject: [6tisch] Comments on the 6top-sublayer and 6top-sf0 drafts

Dear all,

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

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

---

From: Fabrice Theoleyre <[email-masked]>
Date: Mon, 9 Nov 2015 13:59:33 +0100

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

>   <>
> www.ingenieria.udp.cl <http://www.ingenieria.udp.cl/>
> (56 2) 676 8125
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Qin Wang <[email-masked]>
Date: Tue, 10 Nov 2015 15:42:10 +0000 (UTC)

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

     On Monday, November 9, 2015 7:33 AM, Maria Rita PALATTELLA <[email-masked]> wrote:

 #yiv9198189821 #yiv9198189821 -- _filtered #yiv9198189821 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv9198189821 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv9198189821 #yiv9198189821 p.yiv9198189821MsoNormal, #yiv9198189821 li.yiv9198189821MsoNormal, #yiv9198189821 div.yiv9198189821MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv9198189821 a:link, #yiv9198189821 span.yiv9198189821MsoHyperlink {color:blue;text-decoration:underline;}#yiv9198189821 a:visited, #yiv9198189821 span.yiv9198189821MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv9198189821 p.yiv9198189821MsoListParagraph, #yiv9198189821 li.yiv9198189821MsoListParagraph, #yiv9198189821 div.yiv9198189821MsoListParagraph {margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv9198189821 span.yiv9198189821EmailStyle17 {color:#1F497D;}#yiv9198189821 .yiv9198189821MsoChpDefault {} _filtered #yiv9198189821 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv9198189821 div.yiv9198189821WordSection1 {}#yiv9198189821 _filtered #yiv9198189821 {} _filtered #yiv9198189821 {margin-left:58.8pt;} _filtered #yiv9198189821 {margin-left:1.25in;} _filtered #yiv9198189821 {margin-left:1.75in;} _filtered #yiv9198189821 {margin-left:2.25in;} _filtered #yiv9198189821 {margin-left:2.75in;} _filtered #yiv9198189821 {margin-left:3.25in;} _filtered #yiv9198189821 {margin-left:3.75in;} _filtered #yiv9198189821 {margin-left:4.25in;} _filtered #yiv9198189821 {margin-left:4.75in;}#yiv9198189821 ol {margin-bottom:0in;}#yiv9198189821 ul {margin-bottom:0in;}#yiv9198189821 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-masked]]On Behalf Of Prof. Diego Dujovne
Sent: Friday, November 6, 2015 7:31 PM
To: [email-masked]
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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Nov 2015 13:10:54 +0000

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:[email-masked]] On Behalf Of Qin Wang
Sent: mardi 10 novembre 2015 16:42
To: Maria Rita PALATTELLA <[email-masked]>; Prof. Diego Dujovne <[email-masked]>; [email-masked]
Subject: Re: [6tisch] Comments on the 6top-sublayer and 6top-sf0 drafts

Hi Maria Rita and all,

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.

What do you think?

Thanks
Qin

On Monday, November 9, 2015 7:33 AM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:

Diego,

Best Regards,
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: Friday, November 6, 2015 7:31 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] Comments on the 6top-sublayer and 6top-sf0 drafts

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