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
<diego.dujo...@mail.udp.cl> 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 <xvilajos...@uoc.edu>:
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 <l...@cdac.in>:
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
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
