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