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
