Pascal,
I can see your point. Token is useful for Parent to distinguish Retry from new
Request by the Child.
But, I have a stupid question: is it reasonable to allow the Child to ask more
cells before it gets Response to what it already asked?
ThanksQin
On Wednesday, March 9, 2016 2:13 AM, Pascal Thubert (pthubert)
<[email protected]> wrote:
Hello Qin:
Token 1 needs to be the same as token 2 when it is a retry. That's the whole
point.
In your second case, say this is a child asking for a cell:
- If this is a time out because the response from the parent was lost, the
parent should respond with the same cell as in the lost message.
- But if the child got the response and still needs more bandwidth, then the
parent needs to allocate a second cell.
How does the parent know?
The main point of the sequence number is to be able to correlate the retry.
As it goes, it also enables to avoid the serialization of requests but I agree
that is a non goal today.
Regards,
Pascal
Le 8 mars 2016 à 22:10, Qin Wang <[email protected]> a écrit :
Hi all,
I'm not convinced that token is necessary yet. From the discussion in the last
WG meeting, we have agreed that the Token is used in the 6P message exchange
between neighbors. Based on the agreement, let's consider the two following
scenarios.
(1) nodeA send ADD_Request(token=1) to nodeB, and not receive Response from
nodeB before Timeout. Then, nodeA send ADD_Request(token=2) to nodeB, and
receive Response(token=2) from nodeB.
(2) nodeA send ADD_Request to nodeB, and not receive Response from nodeB before
Timeout. Then nodeA send ADD_Request to nodeB again, and receive Response from
nodeB.
The question is if it is possible for nodeA to receive Response(token=1) from
nodeB later in (1). Since nodeA will send the second ADD_Request after Timeout,
I don't think it could happen. If I'm correct, I think the two sequences
function similarly. Thus, I wonder if it is necessary to have the Token
What do you think?
ThanksQin
On Tuesday, March 8, 2016 10:10 AM, Pascal Thubert (pthubert)
<[email protected]> wrote:
Oh yes, Tero,
we agree on the bottom line and on your points.
Cheers,
Pascal
> -----Original Message-----
> From: Tero Kivinen [mailto:[email protected]]
> Sent: mardi 8 mars 2016 15:50
> To: Pascal Thubert (pthubert) <[email protected]>
> Cc: Tengfei Chang <[email protected]>;[email protected]; Prof. Diego
> Dujovne <[email protected]>
> Subject: RE: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P
>
> Pascal Thubert (pthubert) writes:
> > But this is another discussion entirely. It is about the transaction
> > that associates new timeslots to a bundle and why we need a
> > correlator, or transaction ID. I was explaining that if the parent
> > wait for the ack to allocate a slot that was negotiated, and there is
> > no flow after that, then if the ack is lost the child thinks the slot
> > is allocated and the parent does not. The child may start using it
> > wrongly.
>
> Which is why you should not use ACK for anything like that, but instead use
> application level messages for that kind of things.
>
> > The point behind this is that if the transaction does not complete, it
> > must be retried from scratch with the same sequence, or it must time
> > out and roll back.
>
> Receiving or not receiving ACK should not cause transaction to complete or
> not to complete, there must be some kind of application level message to
> indicate that it was successful if that information is needed in the peers.
> --
> [email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
