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 <qinwang6...@yahoo.com>:
> 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 <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 <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
> <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/l istinfo/6tisch
> <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 <usu...@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
>
>
>
--
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
