Subject: [6tisch] Doubts in 3-step transactions mentioned in draft-wang-6tisch-6top-protocol-00

From: Seema Kumar <[email-masked]>
Date: Tue, 26 Apr 2016 16:08:39 +0530

Dear All,

I have few comments with respect to the draft-wang-6tisch-6top-protocol-00.

1) The draft includes 3-step transaction described in Section. 4.1.1,
for negotiation
of cells between two neighbours. In step 4 of 3-step transaction, there is
a mistake. “The SF running on node B selects 2 cells” is written. It should
have been “The SF running on node A selects 2 cells".

2) In 3-step transaction, the requester only specifies number of cells, and
the candidate list is not specified by the requester. I assume, the
neighbouring node is free to choose the candidate list.

When requester sends empty list, what is the motivation behind the
neighbouring node sending the candidate list in second step of 3-step
transaction ?  Is it because the requester has better knowledge about the
cell quality, and therefore can pick the right ones ?

3) In the 3-step transaction, I foresee a problem when there are
concurrent requests
from different neighbours. Regarding concurrent requests, the
draft-wang-6tisch-6top-protocol-00 says “A node MAY support concurrent 6P
Transactions from different neighbors” in Section 4.3.3. A node would reply
BUSY to requester only when it does not have enough resources.

Problem: In the topology specified in the draft, consider node B and C
requires 2 cells each from node A. Node A has 4 or more cells. The SF
chooses 3-step transaction.

                NumCells = 2,[]

Step 1:   B -------------------------> A

             [(1,2),(2,2),(3,5),(4,6)]

Step 2:   B <------------------------- A

                                           NumCells = 2, []

Step 3:                                A <------------------ C

At this step, if Node A specifies [(1,2),(2,2),(3,5),(4,6)] as candidate
list, there will be problem if both Node B and C choose same cells. What
should Node A do at this point ? This problem would not arise in 2-step
transaction.

Currently, if SF0 is used, node A would specify [(1,2),(2,2),(3,5),(4,6)]
as candidate list. Am I right? Then the problem mentioned above would occur.

In my opinion, there is no need for specifying the candidate list in step 2
of 3-step transaction. When requester is not particular about cells, the
neighbouring node can give any 2 cells instead of again asking the
requester to choose.

Regards,
Seema Kumar

---

From: "Satish Anamalamudi (Satish Anamalamudi)" <[email-masked]>
Date: Wed, 27 Apr 2016 02:35:15 +0000

Hello Seema Kumar,

I would like to express my idea for 3-step 6P transaction :

Let us consider a case when requester send candidate list along with NumCells to neighboring node during 6P ADDRequest.

1.      node A (Requester) in Step.2 send the candidate list to Node B(Neighbor node).

2.      If Node B has not all the cells available from candidate list of Node A then Node B can add some cells in Candidate cells during 6P response to node A(step .3).

3.      In step.4, Node A can send the 6P confirmation to node B with scheduled cells.

With this operation, both node A and node B will have equal opportunity to suggest their best available channels.

What do you think ?

With Regards,
Satish.

From: 6tisch [mailto:[email-masked]] On Behalf Of Seema Kumar
Sent: 2016年4月26日 18:39
To: [email-masked]
Subject: [6tisch] Doubts in 3-step transactions mentioned in draft-wang-6tisch-6top-protocol-00

Dear All,

1) The draft includes 3-step transaction described in Section. 4.1.1, for negotiation of cells between two neighbours. In step 4 of 3-step transaction, there is a mistake. “The SF running on node B selects 2 cells” is written. It should have been “The SF running on node A selects 2 cells".

2) In 3-step transaction, the requester only specifies number of cells, and the candidate list is not specified by the requester. I assume, the neighbouring node is free to choose the candidate list.

When requester sends empty list, what is the motivation behind the neighbouring node sending the candidate list in second step of 3-step transaction ?  Is it because the requester has better knowledge about the cell quality, and therefore can pick the right ones ?

3) In the 3-step transaction, I foresee a problem when there are concurrent requests from different neighbours. Regarding concurrent requests, the draft-wang-6tisch-6top-protocol-00 says “A node MAY support concurrent 6P Transactions from different neighbors” in Section 4.3.3. A node would reply BUSY to requester only when it does not have enough resources.

Problem: In the topology specified in the draft, consider node B and C requires 2 cells each from node A. Node A has 4 or more cells. The SF chooses 3-step transaction.

                NumCells = 2,[]

                                           NumCells = 2, []

At this step, if Node A specifies [(1,2),(2,2),(3,5),(4,6)] as candidate list, there will be problem if both Node B and C choose same cells. What should Node A do at this point ? This problem would not arise in 2-step transaction.

Currently, if SF0 is used, node A would specify [(1,2),(2,2),(3,5),(4,6)] as candidate list. Am I right? Then the problem mentioned above would occur.

In my opinion, there is no need for specifying the candidate list in step 2 of 3-step transaction. When requester is not particular about cells, the neighbouring node can give any 2 cells instead of again asking the requester to choose.

Regards,
Seema Kumar

---

From: Seema Kumar <[email-masked]>
Date: Wed, 27 Apr 2016 15:45:50 +0530

Hello Satish,

I agree with the example you have given, both the nodes get equal
opportunity. But, I don't think there is a provision in the current draft
to propose the candidate list in the first step of a 3-step transaction.

With my understanding, the only differentiation between 2-steps and 3-steps
model is who proposes the candidate list.

Whatever the reason is for a 3-step transaction model, I foresee the
problem I mentioned in my previous email (Point 3 of my previous mail). Do
you have any comments on it?

Thanks,
Seema

On Wed, Apr 27, 2016 at 8:05 AM, Satish Anamalamudi (Satish Anamalamudi) <
[email-masked]> wrote:

> Let us consider a case when requester send candidate list along with
> NumCells to neighboring node during 6P ADDRequest.
>
> 2.      If Node B has not all the cells available from candidate list of
> Node A then Node B can add some cells in Candidate cells during 6P response
> to node A(step .3).
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Seema Kumar
> *Sent:* 2016年4月26日 18:39
> *To:* [email-masked]
> *Subject:* [6tisch] Doubts in 3-step transactions mentioned in
> draft-wang-6tisch-6top-protocol-00
>
>
>
> Dear All,
>
>
>
> for negotiation of cells between two neighbours. In step 4 of 3-step
> transaction, there is a mistake. “The SF running on node B selects 2 cells”
> is written. It should have been “The SF running on node A selects 2 cells".
>
>
>
> 2) In 3-step transaction, the requester only specifies number of cells,
> and the candidate list is not specified by the requester. I assume, the
> concurrent requests from different neighbours. Regarding concurrent
> requests, the draft-wang-6tisch-6top-protocol-00 says “A node MAY support
> concurrent 6P Transactions from different neighbors” in Section 4.3.3. A
> node would reply BUSY to requester only when it does not have enough
> resources.
>
>
>
> In my opinion, there is no need for specifying the candidate list in step
> 2 of 3-step transaction. When requester is not particular about cells, the

---

From: Qin Wang <[email-masked]>
Date: Wed, 27 Apr 2016 20:04:28 +0000 (UTC)

Hi Seema and Satish,
Thank you for your comments. We will correct the tpyo you mentioned. 
Regarding to 3-step transaction, let me explain the motivation behind it. Assume node A is a Child of node B, then usually node B has more knowledge about the cell usage, right? But sometime, the Child may find the need to ADD more cells. In this case, the Child will take 3-step transaction to send ADD request to its parent (node B). For this scenario, what do you think about the the 3-step transaction proposed in the draft?
ThanksQin  

    On Wednesday, April 27, 2016 6:16 AM, Seema Kumar <[email-masked]> wrote:

 Hello Satish,
I agree with the example you have given, both the nodes get equal opportunity. But, I don't think there is a provision in the current draft to propose the candidate list in the first step of a 3-step transaction. 
With my understanding, the only differentiation between 2-steps and 3-steps model is who proposes the candidate list.
Whatever the reason is for a 3-step transaction model, I foresee the problem I mentioned in my previous email (Point 3 of my previous mail). Do you have any comments on it?
Thanks,Seema
On Wed, Apr 27, 2016 at 8:05 AM, Satish Anamalamudi (Satish Anamalamudi) <[email-masked]> wrote:

Hello Seema Kumar,I would like to express my idea for 3-step 6P transaction :Let us consider a case when requester send candidate list along with NumCells to neighboring node during 6P ADDRequest.1.     node A (Requester) in Step.2 send the candidate list to Node B(Neighbor node).2.     If Node B has not all the cells available from candidate list of Node A then Node B can add some cells in Candidate cells during 6P response to node A(step .3).3.     In step.4, Node A can send the 6P confirmation to node B with scheduled cells.With this operation, both node A and node B will have equal opportunity to suggest their best available channels.What do you think ? With Regards,Satish.  From: 6tisch [mailto:[email-masked]]On Behalf Of Seema Kumar
Sent: 2016年4月26日 18:39
To: [email-masked]
Subject: [6tisch] Doubts in 3-step transactions mentioned in draft-wang-6tisch-6top-protocol-00 Dear All, I have few comments with respect to the draft-wang-6tisch-6top-protocol-00.  1) The draft includes 3-step transaction described in Section. 4.1.1, for negotiation of cells between two neighbours. In step 4 of 3-step transaction, there is a mistake. “The SF running on node B selects 2 cells” is written. It should have been “The SF running on node A selects 2 cells". 2) In 3-step transaction, the requester only specifies number of cells, and the candidate list is not specified by the requester. I assume, the neighbouring node is free to choose the candidate list. When requester sends empty list, what is the motivation behind the neighbouring node sending the candidate list in second step of 3-step transaction ?  Is it because the requester has better knowledge about the cell quality, and therefore can pick the right ones ?   3) In the 3-step transaction, I foresee a problem when there are concurrent requests from different neighbours. Regarding concurrent requests, the draft-wang-6tisch-6top-protocol-00 says “A node MAY support concurrent 6P Transactions from different neighbors” in Section 4.3.3. A node would reply BUSY to requester only when it does not have enough resources.  Problem: In the topology specified in the draft, consider node B and C requires 2 cells each from node A. Node A has 4 or more cells. The SF chooses 3-step transaction.                 NumCells = 2,[]Step 1:   B -------------------------> A              [(1,2),(2,2),(3,5),(4,6)]Step 2:   B <------------------------- A                                            NumCells = 2, []Step 3:                                A <------------------ C At this step, if Node A specifies [(1,2),(2,2),(3,5),(4,6)] as candidate list, there will be problem if both Node B and C choose same cells. What should Node A do at this point ? This problem would not arise in 2-step transaction. Currently, if SF0 is used, node A would specify [(1,2),(2,2),(3,5),(4,6)] as candidate list. Am I right? Then the problem mentioned above would occur. In my opinion, there is no need for specifying the candidate list in step 2 of 3-step transaction. When requester is not particular about cells, the neighbouring node can give any 2 cells instead of again asking the requester to choose.  Regards,Seema Kumar

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

---

From: "Satish Anamalamudi (Satish Anamalamudi)" <[email-masked]>
Date: Thu, 28 Apr 2016 02:25:42 +0000

Hello Seema kumar,

Please, see the inline below.

                NumCells = 2,[]

                                           NumCells = 2, []

As of my understanding, “ node A(Parent/Neighbor node)” can have multiple interfaces where node-B (Child-1/Requestor) and node-C (Child-2/Requestor) would send the 6P ADDRequest with “NumCells” field to node-A at same time in different interfaces. Once, the Candidate cells are send by node-A to node-B in Step-2 of 3-step transaction then node-A can’t assign the same cells to node-C concurrently. The reason behind this is node-A will mark the candidate cells as “Temporary reserved” in its Chunk. If node-A has some other free cells available in its chunk then step-2 operation to node-C is performed as “6P Response”, otherwise it should be as “BUSY” message.

If 6P ADDRequest from node-B and node-C reach to node-A at exactly same time then node-A should allow only one request at a time to access the chunk information.

Hope my explanation make sense for your Step 3.

With Regards,
Satish.

From: 6tisch [mailto:[email-masked]] On Behalf Of Seema Kumar
Sent: 2016年4月27日 18:16
To: Satish Anamalamudi (Satish Anamalamudi); [email-masked]
Subject: Re: [6tisch] Doubts in 3-step transactions mentioned in draft-wang-6tisch-6top-protocol-00

Hello Satish,

Thanks,
Seema

On Wed, Apr 27, 2016 at 8:05 AM, Satish Anamalamudi (Satish Anamalamudi) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Seema Kumar,

What do you think ?

With Regards,
Satish.

From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Seema Kumar
Sent: 2016年4月26日 18:39
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] Doubts in 3-step transactions mentioned in draft-wang-6tisch-6top-protocol-00

Dear All,

                NumCells = 2,[]

                                           NumCells = 2, []

Regards,
Seema Kumar

---

From: "Satish Anamalamudi (Satish Anamalamudi)" <[email-masked]>
Date: Thu, 28 Apr 2016 02:27:16 +0000

Hello Wang,

For this scenario, what do you think about the the 3-step transaction proposed in the draft?

We are having data transmission in two directions (Upward (Child->Parent) and Downward (Parent->Child)) in RPL networks.

Let us consider a scenario for upward direction (Child -> Parent) for our discussion.

1.       Child may have data to its Parent where it may need to reserve additional cells.

2.       Since nodes can operate with multiple interfaces(6P draft : A node MAY support concurrent 6P Transactions from different neighbors), either Child or Parent cells might be already allocated to neighbor nodes of other Instances (Other DODAG’s) in different interface.

3.       In this case, it is hard to say that Parent cells are available vacant or child cells are available vacant. That’s why I thought that If Child can send the candidate list in Step-1 of step-3 transaction then Parent can decide from it and may have opportunity to input new candidate cells back to the child node in Step-2.

4.       Step-3 will be same as the draft explanation.

Is the above explanation valid ?

With Regards,
Satish

From: Qin Wang [mailto:[email-masked]]
Sent: 2016年4月28日 4:04
To: Seema Kumar; Satish Anamalamudi (Satish Anamalamudi); [email-masked]
Subject: Re: [6tisch] Doubts in 3-step transactions mentioned in draft-wang-6tisch-6top-protocol-00

Hi Seema and Satish,

Thanks
Qin

On Wednesday, April 27, 2016 6:16 AM, Seema Kumar <[email-masked]<mailto:[email-masked]>> wrote:

Hello Satish,

Thanks,
Seema

With Regards,
Satish.

Dear All,

                NumCells = 2,[]

                                           NumCells = 2, []

Regards,
Seema Kumar

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

---

From: Seema Kumar <[email-masked]>
Date: Sat, 30 Apr 2016 10:28:48 +0530

Hi Qin,

Yes, for the given scenario, 3-step transaction is needed.

In the draft, 2-step transaction is like source initiated protocol and
3-step is receiver initiated protocol. Do you think mentioning something
like this, will clarify the meaning of sending an empty candidate cell list
in the first step of 3-step transaction.

Regards,
Seema

On Thu, Apr 28, 2016 at 1:34 AM, Qin Wang <[email-masked]> wrote:

> Regarding to 3-step transaction, let me explain the motivation behind it.
> Assume node A is a Child of node B, then usually node B has more knowledge
> about the cell usage, right? But sometime, the Child may find the need to
> ADD more cells. In this case, the Child will take 3-step transaction to
> send ADD request to its parent (node B). For this scenario, what do you
> think about the the 3-step transaction proposed in the draft?
>
> Thanks
> Qin
>
>
> With my understanding, the only differentiation between 2-steps and
> 3-steps model is who proposes the candidate list.
>