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 <tengfei.ch...@gmail.com>:
> 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 <
> diego.dujo...@mail.udp.cl> 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
>> 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
