Re: [6tisch] 6P and Sf0 issue: Examples of error handling

[Tengfei Chang <[e-mail]>]

Hi Diego,

Yes, that's what I proposed.

The delay that

*starting from receiving the failure of 6P transaction, then forwarding to
SF and SF make the decision to start another 6P transcation*

depends on the position of current slot and next available slot for sending
6P request for Retry.

For example, the slotframe with 11 slots has two shared slots for 6P
transcation: slot 0 and slot 10. If I received the the response at slot0
which indicate the the failure of 6P transcation. SF is able to make the
decision to Retry before slot 10, then the delay for *SF handling Retries*
or* 6P handling the Retries* are the same (delay=10 slots).

If the failure of response is received at slot 10 and SF is not able to
make the decision before the slot 0, then *SF handling Retries* has to wait
until the next slot10 to send the 6P request(delay=11slots), while *6P
handling the Retries *can send it at slot0 with 1 slot delay.

However, I think we can assume that SF can make the decision in a very
short time (within one slot), right?

Tengfei

On Thu, Mar 10, 2016 at 11:56 PM, Prof. Diego Dujovne <
[e-mail]> wrote:

> Tengfei,
>           So, taking into account your proposal, the SF should configure
> the Retry
> Limit and handle the retries at SF layer, leaving 6P to deal only with
> transactions:
> either they are complete and successful or failed and rolled back (even in
> a
> timeout case).
>           Retries shall not be allowed during a 6P transaction: This
> increases
> delay, but reduces complexity.
> What do you think?
>           Regards,
>
>                                         Diego
>
>
>
>
>
> 2016-03-04 6:00 GMT-03:00 Tengfei Chang <[e-mail]>:
>
>> Hello Diego,
>>
>> *For IANA_6TOP_CMD_ROLLBACK command: *
>>
>> I think I understand what you are trying to solve. But using IANA_6TOP_CMD_ROLLBACK
>> has another issue: how to decide when to send the command. I think this is
>> the same question for setting the value of 6P_TIMEOUT.
>> Also if a transaction timeout because of bad link quality or lost
>> connection, sending another packet is not a good idea.
>>
>> *For Retry handling:*
>>
>> First, I think whether retry or not is a decision made by scheduling
>> function. For 6P, it just forwards this message to upper layer (such as SF0)
>>
>> If retries are required, I think it makes sense that retrying within a
>> transaction.
>>
>> What do you think?
>>
>> Tengfei
>>
>> On Thu, Mar 3, 2016 at 9:41 PM, Prof. Diego Dujovne <
>> [e-mail]> wrote:
>>
>>> Dear all,
>>>            One of the sections I would like to add to
>>> the SF0 draft is the examples of error handling.
>>>
>>> One example could be Timeout handling:
>>> When a transaction times out, either a packet is lost,
>>> the destination node lost connectivity or it is too busy
>>> to answer on time.
>>> Consequence: The transaction, in any stage, should
>>> be rolled back by both ends.
>>> Here, both nodes are expected to Timeout.
>>> Section 3.6.2 of the sublayer draft "Aborting a
>>> 6P transaction", cannot be used, since in this case
>>> there is no response.
>>> I propose to issue a rollback command such as
>>> "IANA_6TOP_CMD_ROLLBACK" to the destination
>>> node using the same token from the original transaction,
>>> and do not wait for an answer.
>>> This enables the source node to try a new transaction
>>> before the destination node times out, thus reducing
>>> delay.
>>>
>>> Would you agree in adding this command to reduce
>>> delay?
>>>
>>> Another issue should be Retry handling, in case of
>>> timeout.
>>> Do we allow retries within a transaction?
>>> If we allow retries, the maximum number of retries before
>>> considering a transaction failed should be configured on
>>> the SF.
>>>
>>> Thank you.
>>> Regards,
>>>
>>>                                     Diego Dujovne
>>>
>>>
>>> --
>>> 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
>>> [e-mail]
>>> 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
>