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 protected]> 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 protected]> > 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 protected]> 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 protected]] *On Behalf Of *Seema Kumar > *Sent:* 2016年4月26日 18:39 > *To:* [email protected] > *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 protected] > https://www.ietf.org/mailman/listinfo/6tisch > > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
