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 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
