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
