Thanks yes. I believe I better understand the problem space. I'm familiar with the RADclock work, we've been able to collaborate with them to a small degree in supporting their work. So this is a similar technique optimized for synchronization accuracy using PC based clocks in relatively benign environmental conditions, perhaps not targeting high level system issues like discovery, security, configurability? Perhaps using a different type of filter optimized for the non-Gaussian noise processes dominant in long network links? There has been quite a bit of work done in the industry on packet selection processes which are useful for those types of problems, e.g. MATIE, minTDEV, FPP. There is also work on the disjoint nature of the flows caused by path changes (and just to be up front we have IP in this particular space but there are numerous techniques available). You mention that the clock will differ by a constant. So perhaps the goal is stability over a measurement interval? Is convergence time an issue? If you have developed the implementation, are you looking for interoperability or wider availability in endpoints or some other outcome? In any case, I think there is a great deal of expertise available here in tictoc to assist in matters of actual synchronization research and techniques as well as protocol design, security and even the editing and shepherding of RFCs themselves (which can be the hardest AND longest part :=).
Welcome. -----Original Message----- From: J Ignacio Alvarez-Hamelin [mailto:[email protected]] Sent: Friday, November 17, 2017 10:01 AM To: Greg Dowd <[email protected]> Cc: [email protected] Subject: Re: [TICTOC] A new proposition about clock synchronization on Internet EXTERNAL EMAIL Hi Greg, Yes, I am aware of them. The main problem is when you would like to synchronize two points anywhere on the Internet. For example, consider one computer in Argentina (Buenos Aires) and other at US (Los Angeles), the round trip time is around 140ms and traffic conditions varies a lot. In such context, NTP does not guarantee more than some decades of mili-seconds, PTP required specific hardware, and TSClock cannot work well in such conditions. Our proposal is around ten micro-seconds of error working as a difference clock (definition of [1]) where both clocks differ in a constant. This kind of synchronization is useful when you try to understand the dynamics of delays, where microseconds count. Is it more clear now? [1] Veitch D, Ridoux J, Korada SB. Robust synchronization of absolute and difference clocks over networks. IEEE/ACM Transactions on Networking (TON). 2009 Apr 1;17(2):417-30. Thanks for your time, J. Ignacio _______________________________________________________________ CONICET and Facultad de Ingeniería, Universidad de Buenos Aires Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina +54 (11) 5285 0716 / 5285 0705 e-mail: [email protected] web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ _______________________________________________________________ > On Nov 17, 2017, at 1:44 PM, Greg Dowd <[email protected]> wrote: > > There are any number of protocols designed to synchronize clock frequency > and/or phase between 2, or many, devices over network connections to a > relative or absolute timescale. At the physical layer, there are protocols > such as synchronous ethernet, at the ethernet layer PTP, at the application > layer NTP. Can you provide some detail of your proposal and what unique > problems or configurations it addresses as contrasted with existing protocols? > > ...Greg > > > -----Original Message----- > From: TICTOC [mailto:[email protected]] On Behalf Of J Ignacio > Alvarez-Hamelin > Sent: Friday, November 17, 2017 5:18 AM > To: [email protected] > Subject: [TICTOC] A new proposition about clock synchronization on > Internet > > EXTERNAL EMAIL > > > Dear all, > > I subscribed to this list because several people in IPPM WG pointed out this > WG as the right one for this proposition. I joined the IPPM three years ago, > and I participate in the meetings because part of my work is related to > measurements on the Internet. Motivates with that, my research group > developed a new proposal to synchronize two endpoints on the Internet (if you > would like to measure delays in each way you need the clocks synchronization). > I hope that I could prepare a draft for the IETF 101 about this topic (which > carried some attention on IPPM), and I would like to confirm this interest on > TICTOC, and also to know the deadline for the next meetings. > > With my best regards, > > > > Dr. Ing. José Ignacio Alvarez-Hamelin > _______________________________________________________________ > > CONICET and Facultad de Ingeniería, Universidad de Buenos Aires Av. > Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina > +54 (11) 5285 0716 / 5285 0705 > e-mail: [email protected] > web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/ > _______________________________________________________________ > > > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
