Subject: [TICTOC] A new proposition about clock synchronization on Internet

From: J Ignacio Alvarez-Hamelin <[email-masked]>
Date: Fri, 17 Nov 2017 10:18:28 -0300

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-masked]
web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
_______________________________________________________________

---

From: Greg Dowd <[email-masked]>
Date: Fri, 17 Nov 2017 16:44:16 +0000

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-masked]] On Behalf Of J Ignacio Alvarez-Hamelin
Sent: Friday, November 17, 2017 5:18 AM
To: [email-masked]
Subject: [TICTOC] A new proposition about clock synchronization on Internet

EXTERNAL EMAIL

Dear all,

With my best regards,

CONICET and Facultad de Ingeniería, Universidad de Buenos Aires Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: J Ignacio Alvarez-Hamelin <[email-masked]>
Date: Fri, 17 Nov 2017 15:01:00 -0300

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

> On Nov 17, 2017, at 1:44 PM, Greg Dowd <[email-masked]> wrote:
>

---

From: J Ignacio Alvarez-Hamelin <[email-masked]>
Date: Fri, 17 Nov 2017 15:10:21 -0300

I forgot to say that we also will provide an Open Source version of our proposal.

> On Nov 17, 2017, at 3:01 PM, J Ignacio Alvarez-Hamelin <[email-masked]> wrote:
> 
> Hi Greg,
>

---

From: Greg Dowd <[email-masked]>
Date: Fri, 17 Nov 2017 18:37:11 +0000

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-masked]] 
Sent: Friday, November 17, 2017 10:01 AM
To: Greg Dowd <[email-masked]>
Cc: [email-masked]
Subject: Re: [TICTOC] A new proposition about clock synchronization on Internet

EXTERNAL EMAIL

Hi Greg,

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

---

From: J Ignacio Alvarez-Hamelin <[email-masked]>
Date: Fri, 17 Nov 2017 18:46:18 -0300

The main problem is that traffic is essentially non-Gaussian, and this one of the lines that my research group is working. Because of that you need other techniques to get the synchronization. The first reason of the “difference clock” is the routes on the Internet are essentially asymmetric ones, and it is quite difficult to estimate the degree of asymmetry. The second ones is that you intend to capture the dynamic of traffic, i.e., delay variations, and you are right: it is needed stability during each measurement.  
Then, for the moment the implementation works on Linux based machines, but could be extended to others (with more work, but core is already done). 
Regarding the security problems, like MitM, our proposal can be easily protected against this kind of attacks. 

I hope get one version of the draft ready for next meeting (IETF 101). 

Best,

	J. Ignacio

> On Nov 17, 2017, at 3:37 PM, Greg Dowd <[email-masked]> wrote:
>