Subject: [6tisch] Timeout implementation on 6P/SF0

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 12 May 2017 12:03:33 -0300

Dear all,
            During today's Webex call we discussed transaction
timeout implementation problems. As a result, the proposed
solution is that SF will include a TTL field with the timeout
value that the SF will wait to finish the transaction.
            This will avoid inconsistencies if the transaction
is delayed due to retransmissions or intermediate queues.
            As a consequence, the timeout value will be
implementation-specific.
            Let me know if you agree in this item.
            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

---

From: "Lijo Thomas" <[email-masked]>
Date: Mon, 15 May 2017 16:13:28 +0530

Dear Diego,

As SF0 address a scheduling scheme, it would be better if the algorithm suggest the values.

Or maybe you could detail it with an example or a flow diagram. 

Thanks & Regards,

Lijo Thomas 

From: 6tisch [mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: 12 May 2017 20:34
To: [email-masked]
Subject: [6tisch] Timeout implementation on 6P/SF0

Dear all,

            Regards,

                                 Diego

-- 

DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl <http://www.ingenieria.udp.cl> 
(56 2) 676 8125

-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Fri, 19 May 2017 17:29:27 +0200

Diego,

I agree with Lijo Thomas, could you provide a very simple diagram showing
how the ttl will work. What I understand is that the origin adds the TTL in
the request message and the receiver sets the Timeout to this value once
the request has been received. In this manner the TTL is dependent on the
reception of the request.

am I right?

regards,
Xavi

2017-05-15 12:43 GMT+02:00 Lijo Thomas <[email-masked]>:

> *Thanks & Regards,*
> *Lijo Thomas *
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Prof.
> Diego Dujovne
> *Sent:* 12 May 2017 20:34
> *To:* [email-masked]
> *Subject:* [6tisch] Timeout implementation on 6P/SF0
>
>
>
> Dear all,
>
> ------------------------------------------------------------
> -------------------------------------------------------------------
> ------------------------------------------------------------
> -------------------------------------------------------------------
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 19 May 2017 12:17:50 -0400

Xavi, Lijo:
                The idea I  have been working on is to generate a timeout
value
which is implementation-specific, and that will be sent by SF0 to the
counterpart.
There is no maximum (and the minimum must be 0).
This value will be valid only for the current transaction-neighbour meaning
that for different neighbours and for each of the transactions with them
this
value can change.
The ttl value location on the packet is straightforward, as an 8-bit field
on the
packet after the header. SF0 on the neighbour that starts the transaction
defines
the timeout value which is valid until the end of the transaction.
The timeout time units are also implementation-specific.
Given this description, a diagram could be:

Example Transaction where the timeout does not expire

|TTL Value--------------------------------------------------------|
|A|------First Exchange-------->|B|-----Second Exchange----->|A|

Example Transaction where the timeout expires

|TTL Value-------------------------------------------------|
|A|------First Exchange-------->|B|-----Second Exchange----->|A|

Regards,

                                    Diego

2017-05-19 11:29 GMT-04:00 Xavi Vilajosana Guillen <[email-masked]>:

> (+34) 646 633 681 <+34%20646%2063%2036%2081>

---

From: Qin Wang <[email-masked]>
Date: Mon, 22 May 2017 22:42:29 +0000 (UTC)

Hi Diego and all,
According to my understanding, TTL is the lifetime of a Message and its function is different from Timeout. For example, when nodeA sends a ADD-Request to nodeB, nodeA can set Timeout in a local Timer counting for the maximum waiting time for Response from nodeB, and, at same time, attaches a TTL in ADD-Request message to tell nodeB when the Request message will expire. In this sense, the Timeout value set in nodeA should be greater than TTL value, because the Timeout value should cover not only the valid lifetime value of Request message, but also the time duration for nodeB to sent back Response message.
What do you think?
ThanksQin  

    On Friday, May 19, 2017 12:18 PM, Prof. Diego Dujovne <[email-masked]> wrote:

 Xavi, Lijo:                The idea I  have been working on is to generate a timeout valuewhich is implementation-specific, and that will be sent by SF0 to the counterpart.There is no maximum (and the minimum must be 0).This value will be valid only for the current transaction-neighbour meaningthat for different neighbours and for each of the transactions with them thisvalue can change. The ttl value location on the packet is straightforward, as an 8-bit field on thepacket after the header. SF0 on the neighbour that starts the transaction definesthe timeout value which is valid until the end of the transaction. The timeout time units are also implementation-specific.Given this description, a diagram could be:
Example Transaction where the timeout does not expire

|TTL Value--------------------------------------------------------||A|------First Exchange-------->|B|-----Second Exchange----->|A|

Example Transaction where the timeout expires
|TTL Value-------------------------------------------------||A|------First Exchange-------->|B|-----Second Exchange----->|A|
Regards,
                                    Diego 

Diego,
I agree with Lijo Thomas, could you provide a very simple diagram showing how the ttl will work. What I understand is that the origin adds the TTL in the request message and the receiver sets the Timeout to this value once the request has been received. In this manner the TTL is dependent on the reception of the request.
am I right?
regards,
Xavi
2017-05-15 12:43 GMT+02:00 Lijo Thomas <[email-masked]>:

Dear Diego, As SF0 address a scheduling scheme, it would be better if the algorithm suggest the values. Or maybe you could detail it with an example or a flow diagram.   Thanks & Regards,Lijo Thomas   From: 6tisch [mailto:[email-masked] g] On Behalf Of Prof. Diego Dujovne
Sent: 12 May 2017 20:34
To: [email-masked]
Subject: [6tisch] Timeout implementation on 6P/SF0 Dear all,            During today's Webex call we discussed transactiontimeout implementation problems. As a result, the proposedsolution is that SF will include a TTL field with the timeout 
value that the SF will wait to finish the transaction.            This will avoid inconsistencies if the transactionis delayed due to retransmissions or intermediate queues.            As a consequence, the timeout value will be 
implementation-specific.            Let me know if you agree in this item.             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
------------------------------ ------------------------------ ------------------------------ ------------------------------ -------
[ C-DAC is on Social-Media too. Kindly follow us at: 
Facebook: https://www.facebook.com/CDACI NDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
------------------------------ ------------------------------ ------------------------------ ------------------------------ -------
______________________________ _________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/l istinfo/6tisch

-- 

| Dr. Xavier Vilajosana
Wireless Networks Lab
Internet Interdisciplinary Institute (IN3)
Professor
(+34) 646 633 681
[email-masked]
http://xvilajosana.org
http://wine.rdi.uoc.edu
 |
| Parc Mediterrani de la Tecnologia 
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain |

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Mon, 22 May 2017 18:53:17 -0400

Qin,
      I do agree, and I interpret that I have expressed that as the timeout
for the full transaction. In the graph, Node B should not send any response
packet after the timeout has expired. A full transaction is composed either
by two messages or by three messages.
      From the difference you mention from ttl to timeout, just replace the
ttl
with timeout. I probably used them interchangeably when I should have not.
       Thanks for the remark,

                                         Diego

2017-05-22 18:42 GMT-04:00 Qin Wang <[email-masked]>:

> Hi Diego and all,
>
> According to my understanding, TTL is the lifetime of a Message and its
> function is different from Timeout. For example, when nodeA sends a
> ADD-Request to nodeB, nodeA can set Timeout in a local Timer counting for
> the maximum waiting time for Response from nodeB, and, at same time,
> attaches a TTL in ADD-Request message to tell nodeB when the Request
> message will expire. In this sense, the Timeout value set in nodeA should
> be greater than TTL value, because the Timeout value should cover not only
> the valid lifetime value of Request message, but also the time duration for
> nodeB to sent back Response message.
>
> What do you think?
>
> Thanks
> Qin
>
>
> *From:* 6tisch [mailto:[email-masked] g <[email-masked]>]
> *On Behalf Of *Prof. Diego Dujovne
> ------------------------------ ------------------------------
> ------------------------------ ------------------------------ -------
> Facebook: https://www.facebook.com/CDACI NDIA
> <https://www.facebook.com/CDACINDIA> & Twitter: @cdacindia ]
>
> ------------------------------ ------------------------------
> ------------------------------ ------------------------------ -------
>
> <https://www.ietf.org/mailman/listinfo/6tisch>
>
>
>
>
> --
> Dr. Xavier Vilajosana
> Wireless Networks Lab
>