Re: [6tisch] SF Timeout calculation (Ticket #53)

Nicola, I created a new thread to discuss this item. Can you continue there so as separate the topics? Thank you. Regards, Diego 2016-10-31 19:29 GMT-03:00 Nicola Accettura : > Diego, > > defining priorities about the

Re: [6tisch] SF Timeout calculation (Ticket #53)

Diego, from what I saw it does not help. That is a way to associate requests to responses in the transaction. If the timeout expires on A, a response arriving out of time will not be considered. If the 6P response from B to A is out of time for A, that response should be immediately trashed: the

Re: [6tisch] SF Timeout calculation (Ticket #53)

Diego, defining priorities about the management of packets is implementation specific, I guess. But I can be wrong. To be honest, from what I saw in practical implementations, the best is to give the highest priority to 6P packets both on shared and dedicated cells, because they are in charge to

Re: [6tisch] SF Timeout calculation (Ticket #53)

Nicola, One recent inconsistency check on 6P is the Schedule Generation, defined on the 6top protocol draft on: 4.3.11. Generation Management section. Maybe this helps reducing the inconsistency you are mentioning without increasing the timeout. Regards,

Re: [6tisch] SF Timeout calculation (Ticket #53)

Hi Nicola and Diego, Since we agree Timeout is needed no matter what schemes we will choose, let's make calculation about the Timeout in different schemes. Assume:t1: Node A 6top prepares ADD Requestt2: Node A 6top sends out ADD Request, ending with MAC-ACK successt3: Node B 6top processes ADD

Re: [6tisch] SF Timeout calculation (Ticket #53)

Nicola, I would try to focus on the draft, however, let me answer briefly the shared/dedicated point of view below. Regards, Diego 2016-10-31 15:18 GMT-03:00 Nicola Accettura : > Hi Diego, > > thank you for your answer too. >

Re: [6tisch] SF Timeout calculation (Ticket #53)

Hi Diego, thank you for your answer too. However there are two points I would like to point out. First, the mac-layer ack is in fact the TSCH ack, that travels on the air during the same timeslot of the data packet. It is sent if the data packet is unicast, either on shared or on dedicated

Re: [6tisch] SF Timeout calculation (Ticket #53)

Dear all, I answer inline. Regards, Diego 2016-10-31 13:23 GMT-03:00 Nicola Accettura : > Hi Qin, > > I'm very happy for your feedback. > > I was just considering the transaction as a 6P one, you have bettered off > that by

Re: [6tisch] SF Timeout calculation (Ticket #53)

Hi Qin, I'm very happy for your feedback. I was just considering the transaction as a 6P one, you have bettered off that by introducing also the relationship between 6P and SF0 in each part of the transaction. This is perfect now! Actually I did not propose to delete the timeout. I perfectly

Re: [6tisch] SF Timeout calculation (Ticket #53)

Diego, all, the timeout obviously must start when the ack is received. I agree in total. Though, you still need to get the timeout proportional to TXATTEMPTS and also to the maximum backoff window. Why? Call A the node that is requesting cells, and B the node that is asked for cells. Node A

[6tisch] SF Timeout calculation (Ticket #53)

Dear all, Yesterday, we had a discussion about ticket #53 from the issue tracker, on the way to calculate the SF0 timeout value. There is current a proposal to calculate the timeout on SF0 between the arrival of the MAC-layer ACK for the request packet and the arrival of the