I agree with Xavi and Pascal on the use of the token:
- To enable future concurrent requests
- To enable retries.
However, in another thread Tengfei proposed that the SF should
take care of retries and 6P only respond to SFs as "OK" or "FAIL"
transaction.
Regards,
Diego
2016-03-09 14:27 GMT-03:00 Pascal Thubert (pthubert) <[email protected]>:
> Never seen a stupid question from you, Qin : )
>
>
>
> I agree with you actually.
>
>
>
> By “As it goes, it also enables to avoid the serialization of requests
> but I agree that is a non goal today.” I meant that the child will
> probably serialize hos requests, iow wait for one completion before it asks
> for more. But with the token / seqnum we are open if one day we decide
> otherwise…
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* Qin Wang [mailto:[email protected]]
> *Sent:* mercredi 9 mars 2016 16:48
> *To:* Pascal Thubert (pthubert) <[email protected]>
> *Cc:* Tero Kivinen <[email protected]>; [email protected]; Prof. Diego Dujovne
> <[email protected]>; Tengfei Chang <[email protected]>
> *Subject:* Re: [6tisch] 6P and Sf0 issue: Token to identify transactions
> in 6P
>
>
>
> 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?
>
>
>
> Thanks
>
> Qin
>
>
>
> 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?
>
>
>
> Thanks
>
> Qin
>
>
>
>
>
> 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
>
>
>
>
>
--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
