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

From: "Satish Anamalamudi (Satish Anamalamudi)" <[email-masked]>
Date: Wed, 4 May 2016 05:58:50 +0000

Hello Qin and Seema,

I would like to clarify one question in 3-step transaction.

1.      Let’s think that the “requester” send the NumCells with empty candidate list in 6PADDRequest during step. 1.
2.      Subsequently, neighboring node send 6PADDResponse with candidate list in Step.2.
3.      If requester doesn’t have free cells available with the candidate list of neighboring node then how will requester handle the operation? (This case may be possible when requester is handling multiple interfaces with multiple instances)
4.      Will requester send the 6PADDRequest again to neighboring node for new cell list?
With Regards,
Satish.

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

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

Thanks
Qin

On Wednesday, April 27, 2016 6:16 AM, Seema Kumar <[email-masked]<mailto:[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]<mailto:[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]<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,

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

---

From: "Satish Anamalamudi (Satish Anamalamudi)" <[email-masked]>
Date: Mon, 16 May 2016 05:56:07 +0000

Hello everyone,
@Pascal : Thank you for your explanation that why child can’t initiate the candidate list in 3-step transaction for cell scheduling and cell adaptation.
@ Qin Wang : I think it’s good to explicitly mention that 3-step transaction is for Child->Parent cell scheduling and 2-step transaction is for Parent -> Child cell scheduling in the 6top draft. This makes the readers clear about why draft needs 2- and 3-step transactions. What do you think ?
With Regards,
Satish.

     *   "Doubts in 3-step transactions mentioned in draft-wang-6tisch-6top-protocol-00"
        *   Satish proposes a new mechanism for the 3-way transaction
        *   the scheduling function decides what the cell list means.
        *   Seema: in the new proposal it is difficult to differentiate between the 2 step and the 3 step mechanism as the candidate list is present in the first message in both cases.
        *   The SF is the responsible of deciding what of the 6top mechanisms.
        *   the 6top protocol is the carrier of the data. the SF decides what if 2 or 3 steps are used. We have not considered that both models can be used at the same time. In case this is needed, the metadata field can be used to indicate that.
        *   Pascal: If the requester is a child, then it does not know which chunk is owned by the parent and it cannot propose a candidate list of cells. What it could do is propose a candidate list of slot offsets that are free in its schedule
From: 6tisch [mailto:[email-masked]] On Behalf Of Satish Anamalamudi (Satish Anamalamudi)
Sent: 2016年5月4日 13:59
To: Seema Kumar; Qin Wang
Cc: [email-masked]
Subject: Re: [6tisch] Doubts in 3-step transactions mentioned in draft-wang-6tisch-6top-protocol-00

Hello Qin and Seema,

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

Hi Qin,

Regards,
Seema

Thanks
Qin

Hello Satish,

Thanks,
Seema

With Regards,
Satish.

Dear All,

                NumCells = 2,[]

                                           NumCells = 2, []

Regards,
Seema Kumar

---

From: "S.V.R.Anand" <[email-masked]>
Date: Thu, 19 May 2016 13:58:57 +0530

Hello Satish and All,

While the child can't initiate the candidate list by pinning down the 
cells, it
should have have the ability to indicate the delay bounds to the parent 
so that
the parent can try to locate cells that meet this requirement. The child 
can then
choose what is appropriate. Does this sound reasonable ?

Anand

On Monday 16 May 2016 11:26 AM, Satish Anamalamudi (Satish Anamalamudi) 
wrote:
>  > Hello everyone, > > @Pascal : Thank you for your explanation that 
why child cant initiate the candidate list in 3-step transaction for 
cell scheduling and cell adaptation. > > @ Qin Wang : I think its good 
to explicitly mention that 3-step transaction is for Child->Parent cell 
scheduling and 2-step transaction is for Parent -> Child cell scheduling 
in the 6top draft. This makes the readers clear about why draft needs 2- 
and 3-step transactions. What do you think ? > > With Regards, > > 
Satish. > >         "Doubts in 3-step transactions mentioned in 
draft-wang-6tisch-6top-protocol-00" >             Satish proposes a new 
mechanism for the 3-way transaction >             the scheduling 
function decides what the cell list means. >             Seema: in the 
new proposal it is difficult to differentiate between the 2 step and the 
3 step mechanism as the candidate list is present in the first message 
in both cases. >             The SF is the responsible of deciding what 
of the 6top mechanisms. >             the 6top protocol is the carrier 
of the data. the SF decides what if 2 or 3 steps are used. We have not 
considered that both models can be used at the same time. In case this 
is needed, the metadata field can be used to indicate that. 
 >             Pascal: If the requester is a child, then it does not 
know which chunk is owned by the parent and it cannot propose a 
candidate list of cells. What it could do is propose a candidate list of 
slot offsets that are free in its schedule > > From: 6tisch 
[mailto:[email-masked]] On Behalf Of Satish Anamalamudi (Satish 
Anamalamudi) > Sent: 2016t54å 13:59 > To: Seema Kumar; Qin Wang > Cc: 
[email-masked] > Subject: Re: [6tisch] Doubts in 3-step transactions 
mentioned in draft-wang-6tisch-6top-protocol-00 > > > > Hello Qin and 
Seema, > > > > I would like to clarify one question in 3-step 
transaction. > > > > 1.      Lets think that the requester send the 
NumCells with empty candidate list in 6PADDRequest during step. 1. > > 
2.      Subsequently, neighboring node send 6PADDResponse with candidate 
list in Step.2. > > 3.      If requester doesnt have free cells 
available with the candidate list of neighboring node then how will 
requester handle the operation? (This case may be possible when 
requester is handling multiple interfaces with multiple instances) > > 
4.      Will requester send the 6PADDRequest again to neighboring node 
for new cell list? > > With Regards, > > Satish. > > > > From: Seema 
Kumar [mailto:[email-masked]] > Sent: 2016t430å 12:59 > To: Qin 
Wang > Cc: Satish Anamalamudi (Satish Anamalamudi); [email-masked] > 
Subject: Re: [6tisch] Doubts in 3-step transactions mentioned in 
draft-wang-6tisch-6top-protocol-00 > > > > 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: > > 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? > > > > Thanks > 
 > Qin > > > > 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: 2016t426å 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 > > > > > 
 > > _______________________________________________ > 6tisch mailing 
list > [email-masked] > https://www.ietf.org/mailman/listinfo/6tisch