Hello Satish and All,
While the child can't initiate the candidate list by pinning down the
cells, it
should have have the ability to indicate the delay bounds to the parent
so that
the parent can try to locate cells that meet this requirement. The child
can then
choose what is appropriate. Does this sound reasonable ?
Anand
On Monday 16 May 2016 11:26 AM, Satish Anamalamudi (Satish Anamalamudi)
wrote:
> Hello everyone, > > @Pascal : Thank you for your explanation that
why child cant initiate the candidate list in 3-step transaction for
cell scheduling and cell adaptation. > > @ Qin Wang : I think its 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: 2016t54å 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. Lets 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 doesnt 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: 2016t430å 12:59 > To: Qin
Wang > Cc: Satish Anamalamudi (Satish Anamalamudi); [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]>
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: 2016t426å 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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
