Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

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.dujovne@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) <pthubert@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:qinwang6top@yahoo.com]
>> *Sent:* mercredi 9 mars 2016 16:48
>> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>
>> *Cc:* Tero Kivinen <kivinen@iki.fi>; 6tisch@ietf.org; Prof. Diego
>> Dujovne <diego.dujovne@mail.udp.cl>; Tengfei Chang <
>> tengfei.chang@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) <
>> pthubert@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 <qinwang6top@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) <
>> pthubert@cisco.com> wrote:
>>
>>
>>
>> Oh yes, Tero,
>>
>> we agree on the bottom line and on your points.
>>
>> Cheers,
>>
>> Pascal
>>
>>
>> > -----Original Message-----
>> > From: Tero Kivinen [mailto:kivinen@iki.fi]
>> > Sent: mardi 8 mars 2016 15:50
>> > To: Pascal Thubert (pthubert) <pthubert@cisco.com>
>> > Cc: Tengfei Chang <tengfei.chang@gmail.com>; 6tisch@ietf.org; Prof.
>> Diego
>> > Dujovne <diego.dujovne@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.
>> > --
>> > kivinen@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
>