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 protected]] On Behalf Of Satish Anamalamudi
(Satish Anamalamudi)
Sent: 2016年5月4日 13:59
To: Seema Kumar; Qin Wang
Cc: [email protected]
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. 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 protected]]
Sent: 2016年4月30日 12:59
To: Qin Wang
Cc: Satish Anamalamudi (Satish Anamalamudi);
[email protected]<mailto:[email protected]>
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 protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>]
On Behalf Of Seema Kumar
Sent: 2016年4月26日 18:39
To: [email protected]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
