Re: [v6ops] draft-elkins-v6ops-ipv6-pdm-recommended-usage-00

[Nalini Elkins <[e-mail]>]

Joel,

The synchronization and granularity of the timestamps for our proposal is one of the two outstanding issues.   I will take up the other issue (is this proposal useful for the Internet?) in a separate thread.

We have also had some discussions with the folks in the IPPM group, so I am copying that working group on this thread.

To restate the issues as I understand them (please correct me if I am wrong):

1.   Timestamp correlation depends on both ends being synchronized using a standard mechanism.
2.   This is a question of 'best practices'.
3.   Is the timestamp of sufficient quality or granularity to be useful.

The answers to 1. and 2.  is yes.   Of course.   If people find this kind of data to be of use, then they will synchronize.  It is my understanding that activities other than those proposed by us require time synchronization.   So, it is quite likely that people may be doing this already.

The answer to 3. is an interesting one.   I will cite a paper from Dr. Joachim Fabini.  It is available at:

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6553584

The significant passage is on page 7:

"Mobile client and server are both accurately timesynchronized using EM-406A GPS modules with PPS support.    The RS232 level conversion required for this GPS module is implemented by a SparkFun 8334 GPS evaluation board
which has been extended by the PPS circuit as proposed in [8]. The Network Time Protocol Daemon (ntp) synchronizes both endpoints accurately with global time using the evaluation board’s level-converted PPS and GPS time signals accessed by the kernel using native RS232 serial interfaces. Tests over several weeks have shown that this setup can synchronize the system clock accurately down to 5μs to global time. Even if deployed in nonoptimum conditions (indoor, 1st floor, street view with 6-floor opposite building), the clock accuracy is better than 50μs." 

I believe that 5 - 50 microseconds of accuracy is sufficient for triage.  In our proposal, we want three times: inbound network path, the server processing time, or the outbound network path.  I believe that for accurate triage, we will be able to say that the problem is in the inbound network path, the server, or the outbound network path even if the clocks vary by 50 microseconds.  In my experience, the differences between the 3 calculations which we want vary by quite a bit more than 50 microseconds.   I actually have quite a bit of data available to prove this from running diagnostics with a number of companies and over the Internet in the last few years and I will do a paper (when I get a free weekend!).   I will discuss my findings with the IPPM group as I believe this to be of interest to them.

For those who may be new to this discussion, they may care to look at our proposals:

http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-00


http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-rt-needed-00


http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-packet-sequence-needed-00


http://www.ietf.org/id/draft-elkins-v6ops-ipv6-pdm-recommended-usage-00.txt


Thanks,

Nalini Elkins
Inside Products, Inc.
[phone]
www.insidethestack.com



________________________________
From: joel jaeggli <[e-mail]>
To: Nalini Elkins <[e-mail]>; IPv6 Ops WG <[e-mail]> 
Sent: Thursday, August 1, 2013 6:45 AM
Subject: draft-elkins-v6ops-ipv6-pdm-recommended-usage-00


Since I ran into you in the hall and the dicussion turned to ntp...

I'll try and be succinct, and as a non-expert in the time field this
should be taken with a grain of salt.

The generic utility of a high-resultion time-stamp is imho dodgey
outside of situations where the clocks are deliberately syncronized and
traceable to a common standard whether the protocol used for this is ntp
or ieee 1588 (or since this is the ietf PTPV2) . While this is tractable
for devices in a single span of control, the agruement that ntp might be
suffcient to make this timstamp useful generically between two
aribitratry devices where this functionality may need to be enabled is
imho a hard one to assert.

It is a set of operational practice and discipline moreso than the
choice of technology that allows for a high-resolution timestamp to have
sufficient precision to be useful between hosts.

joel