Diego, I think it's two different things.
1. Token is capable to identify a retries or a new transaction. (As Pascal said.) 2. SF decides whether retry or not. (It's said in another thread) They are not collisions. Tengfei On Fri, Mar 11, 2016 at 3:28 PM, Prof. Diego Dujovne < diego.dujo...@mail.udp.cl> wrote: > 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) <pthub...@cisco.com>: > >> 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:qinwang6...@yahoo.com] >> *Sent:* mercredi 9 mars 2016 16:48 >> *To:* Pascal Thubert (pthubert) <pthub...@cisco.com> >> *Cc:* Tero Kivinen <kivi...@iki.fi>; 6tisch@ietf.org; Prof. Diego >> Dujovne <diego.dujo...@mail.udp.cl>; Tengfei Chang < >> tengfei.ch...@gmail.com> >> *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) < >> pthub...@cisco.com> 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 <qinwang6...@yahoo.com> 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) < >> pthub...@cisco.com> wrote: >> >> >> >> Oh yes, Tero, >> >> we agree on the bottom line and on your points. >> >> Cheers, >> >> Pascal >> >> >> > -----Original Message----- >> > From: Tero Kivinen [mailto:kivi...@iki.fi] >> > Sent: mardi 8 mars 2016 15:50 >> > To: Pascal Thubert (pthubert) <pthub...@cisco.com> >> > Cc: Tengfei Chang <tengfei.ch...@gmail.com>; 6tisch@ietf.org; Prof. >> Diego >> > Dujovne <diego.dujo...@mail.udp.cl> >> > 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. >> > -- >> > kivi...@iki.fi >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> 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 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
