Dear all,
I answer inline.
Regards,
Diego
2016-10-31 13:23 GMT-03:00 Nicola Accettura <[email protected]>:
> 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 agree with
> you in saying that we need timeouts to preserve the system from Failed
> transactions.
>
> I was proposing instead to have a timeout on both sides of the
> transaction, but shorter than the one that would be required if the
> transaction was 2-way:
>
> 1. node A will start the timeout after receiving the mac-layer ack
> from node B for the ADD request: if node A receives an ADD response from B
> during the timeout window, the transaction will continue, otherwise, the
> transaction is considered as failed
>
> This is what I proposed on the initial mail; 6P propagates the MAC layer
ACK, thus becoming a 6P ACK.
>
> 1. Node B will start the timeout after receiving the mac-layer ack
> from node A for the ADD response: if node B receives a 6P ACK from A during
> the timeout window, the transaction will continue, otherwise, the
> transaction is considered failed
>
> (This is 2, but numbering is automatic and gmail fails to understand this
is inline answering)
And this is the expected reverse path, doing the same as the forward path.
> Please, note that, if A received the ADD response in the 'minimal' shared
> cell and the dedicated TX cells are allocated just after that reception,
> the 6P ACK will be sent during the same slotframe in the first dedicated TX
> cell.
>
Why negotiations should be done in dedicated cells? From my point of view,
dedicated cells are for data and shared cells for any kind of signalling
and/or negotiation.
>
> Just speaking about possible extensions for more complex uses: the 6P ACK
> could also hold a flag to declare it as a NACK. If the timeout on node A
> was expired, and it received a 6P answer out of time by B, it can send back
> a NACK to let B stop its own timeout and let it delete the RX cells
> previously half-opened.
>
> What do you think?
>
>
Again, this is a possible change for 6P (and not SF0). I ask Qin and Xavi
what is their opinion
about it.
> Nicola
>
>
> 2016-10-31 16:20 GMT+01:00 Qin Wang <[email protected]>:
>
>> Hi Nicola,
>>
>> I want to confirm my understanding first.
>>
>> Your proposal is to introduce a new 6P message, i.e. 6P ACK message, into
>> a transaction, then the sequence of a original 2-way ADD transaction will
>> be:
>> (1) node A SF0 sets "adding TX cells" OPEN, and 6top layer sends ADD
>> request to nodeB
>> (2) node B 6top layer receives ADD Request, SF0 sets "adding RX cells"
>> OPEN, and 6top layer sends ADD Response to node A
>> (3) node A 6top layer receives ADD Response, SF0 adds TX cells and sets
>> "adding TX cells" CLOSED, and 6top layer sends 6P ACK to node B
>> (4) node B 6top layer receives 6P ACK, SF0 adds RX cells and sets "adding
>> RX cells" CLOSE.
>>
>> Is my understanding correct? In addition, the proposed scheme will not
>> need Timeout. Is it what you mean?
>>
>> But, I still think the scheme can not avoid a Timeout. Otherwise, how
>> node A or node B can stop a Failed transaction if something happens?
>>
>> Thanks
>> Qin
>>
>>
>>
>> On Saturday, October 29, 2016 2:18 PM, Nicola Accettura <
>> [email protected]> wrote:
>>
>>
>> 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 sends a request and gets a mac layer ack from B. A starts
>> the timeout. B sends a packet, but it's lost. Sends another packet and it
>> is lost... until the last attempt which is successful: B gets a link layer
>> ack from A. So B allocates cells as RX.
>>
>> This confirms that the timeout should be proportional to TXATTEMPTS. And
>> to the maxium backoff window. If there is only one shared cell, according
>> to 'minimal', the timeout is proportional also to the slotframesize. If
>> some implementation considers more than one shared cell per slotframe, the
>> timeout can be smaller. At this point, I would say that the unity of
>> measure of the timeout should be the number of executed shared cells, so
>> that the timeout can be safely be proportional just to the product of
>> TXATTEMPTS and the maximum backoff window.
>>
>> Yes, this causes to have a very long timeout, with possible (and actually
>> frequent) desynchronizations. Especially when the network is forming, all
>> nodes will ask for dedicated cells, many 6P packets will get lost.
>> Keepalives will be triggered, but this worsen the situation. Everything is
>> very very bad.
>>
>> Is that possible to have a shorter timeout?
>>
>> My answer is 'yes'. But we need something else: a 6P ACK.
>>
>> In fact, assume that A sent a request, B acked at MAC layer. Then B
>> (maybe after many tries, if the responses have been lost, and this is
>> possible in the 'minimal' shared cell due to collisions in big networks) is
>> finally able to send an answer that is correctly received by A and A sends
>> an ack at mac layer. B adds cells as RX and expects A to open the same
>> cells as TX.
>>
>> 'Good!' one would say.
>>
>> Wrong! Node A has acknowledged at MAC layer the correct reception of the
>> answer by B but will process the 6P packet after that. If the timeout is
>> too short, that packet will be considered out of time. And the TX cells
>> will not be allocated. With some RX cells open on node B.
>>
>> One can think of a timeout to garbage collect on B. But I'm not sure this
>> would be very efficient, there's the probability of false positive.
>>
>> A 6P ack would make the 6P negotiation reliable. B can 'half' open the RX
>> side after receiving the mac layer ack from A. A will open the TX side
>> after sending the mac layer ack, it the 6P response was in time. It will
>> send the 6P ack possibly in the newly created dedicated cell, so
>> decongesting the shared cell of 'minimal'. If B receives the 6P ack, it
>> will be sure that the RX side is open completely without possible
>> impairment with the node A schedule knowledge.
>>
>> Instead, if the 6P response was out of time, A will not send any 6P ack,
>> will not open the TX side. B will not receive any 6P ack within a timeout
>> (that can be the same length as that starting on the A side after the
>> reception of the mac layer ack to the request packet) and when that expires
>> will delete the RX cells that were 'half' opened.
>>
>> With this, it is not possible to get suspicious cells allocations on the
>> RX side. There's still the possibility that a TX side is open with the RX
>> side not open. But for that, 6P or SF will manage a relocation.
>>
>> Think about the 6P packet as the third part of a 3-way-handshake.
>>
>> Of course, it's obvious that I'm strongly in favor of a 6P ack
>> definition, more than having a big timeout.
>>
>> Does it make sense?
>>
>> Nicola
>>
>>
>> 2016-10-29 18:44 GMT+02:00 Prof. Diego Dujovne <[email protected]
>> >:
>>
>> 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 response packet.
>> In order to achieve this calculation, the 6P protocol must
>> signal the arrival of the request ACK packet so as to start
>> the timer countdown.
>> Using this method, we avoid very long timeouts set
>> to the max value of the number of TXATTEMPTS and the
>> maximum backoff value.
>> Graphically:
>>
>> SF |REQUEST| |timer-----|RESPONSE|
>> ^
>> 6P |REQUEST| | |RESPONSE|
>> MAC LAYER |REQUEST| |ACK| |RESPONSE| |ACK|
>>
>> I would like to know if your thougthts about this idea.
>> Thank you.
>> Regards,
>>
>> Diego
>>
>> --
>> DIEGO DUJOVNE
>> Profesor Asociado
>> Escuela de Informática y Telecomunicaciones
>> Facultad de Ingeniería - Universidad Diego Portales - Chile
>> www.ingenieria.udp.cl
>> (56 2) 676 8125
>>
>> ______________________________ _________________
>> 6tisch mailing list
>> [email protected]
>> https://www.ietf.org/mailman/ listinfo/6tisch
>> <https://www.ietf.org/mailman/listinfo/6tisch>
>>
>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>>
>
--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
