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

[Prof. Diego Dujovne]

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 :

> 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
>
>
> On Friday, May 19, 2017 12:18 PM, Prof. Diego Dujovne <
> diego.dujo...@mail.udp.cl> wrote:
>
>
> 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 :
>
> 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 :
>
> 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:6tisch-boun...@ietf.or g <6tisch-boun...@ietf.org>]
> *On Behalf Of *Prof. Diego Dujovne
> *Sent:* 12 May 2017 20:34
> *To:* 6tisch@ietf.org
> *Subject:* [6tisch] Timeout implementation on 6P/SF0
>
> 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
>
> -- --
> -- -- ---
> [ 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 take

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

[Qin Wang]

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 
 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 

2017-05-19 11:29 GMT-04:00 Xavi Vilajosana Guillen :

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 :

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:6tisch-boun...@ietf.or g] On Behalf Of Prof. Diego Dujovne
Sent: 12 May 2017 20:34
To: 6tisch@ietf.org
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
6tisch@ietf.org
https://www.ietf.org/mailman/l istinfo/6tisch





-- 

| Dr. Xavier Vilajosana
Wireless Networks Lab
Internet Interdisciplinary Institute (IN3)
Professor
(+34) 646 633 681
xvilajos...@uoc.edu
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 |

  
­



-- 
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
6tisch@ietf.org
h

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

[Prof. Diego Dujovne]

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 :

> 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 :
>
>> 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:6tisch-boun...@ietf.org] *On Behalf Of *Prof.
>> Diego Dujovne
>> *Sent:* 12 May 2017 20:34
>> *To:* 6tisch@ietf.org
>> *Subject:* [6tisch] Timeout implementation on 6P/SF0
>>
>>
>>
>> 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
>>
>> 
>> ---
>> [ 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.
>> 
>> ---
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
>
> --
> Dr. Xavier Vilajosana
> Wireless Networks Lab
>
> *Internet Interdisciplinary Institute (IN3)Professor*
> (+34) 646 633 681 <+34%20646%2063%2036%2081>
> xvilajos...@uoc.edu 
> 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
> [image: Universitat Oberta de Catalunya]
> ­
>



-- 
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
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Xavi Vilajosana Guillen]

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 :

> 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:6tisch-boun...@ietf.org] *On Behalf Of *Prof.
> Diego Dujovne
> *Sent:* 12 May 2017 20:34
> *To:* 6tisch@ietf.org
> *Subject:* [6tisch] Timeout implementation on 6P/SF0
>
>
>
> 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
>
> 
> ---
> [ 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.
> 
> ---
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
xvilajos...@uoc.edu 
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
[image: Universitat Oberta de Catalunya]
­
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Lijo Thomas]

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:6tisch-boun...@ietf.org] On Behalf Of Prof. Diego Dujovne
Sent: 12 May 2017 20:34
To: 6tisch@ietf.org
Subject: [6tisch] Timeout implementation on 6P/SF0

 

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


---
[ 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.
---

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch