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

[Nalini Elkins <[e-mail]>]

Joel,


>>network devices are by-in-large not built with embedded GPS.

We are not talking about network devices.   Our header is a Destination Options header which ONLY end hosts need to be concerned with.   Your data is very interesting but it is not what we are talking about.

What is of concern is what actual end hosts can do.  This is a conversation that I will be starting with the OS vendors.    That is why Joachim's paper was of interest.


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]>; "[e-mail]" <[e-mail]> 
Cc: ALFRED C (AL) <[e-mail]>; "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]> 
Sent: Wednesday, August 28, 2013 3:17 AM
Subject: Re: draft-elkins-v6ops-ipv6-pdm-recommended-usage-00


On 8/27/13 5:48 AM, Nalini Elkins wrote:
> 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." 
network devices are by-in-large not built with embedded GPS.

By way of demonstration of the level of measuerment error I expect.
Juniper RPM can do asic based timestamping on measurement traffic
between two devices. I have a path, the length of which does not vary by
much (it's a wave-length between san jose and ashburn virginia). the
routers derive time from a clustered of peered stratum 2 servers which
in turn are clients of stratum-1 sources that are traceable to NIST. 

in the following graph:

http://i.imgur.com/AkDRs9D.png

the top line is the RTT as measured by the sending router.

the green line is the difference between the timestamp applied by the
reciveing router in ashburn and the timestamp applied by the sending
router, and the redline is the differnce between the ashburn router
sending timestamp and the timestamp genrated when the packet is recieved
again in san jose.

the vertical axis is thousands of microseconds.

I'm farily comfortable that my NTP and my devices clocks aren't totaly
busted. I'm also comfortable with the idea that there's substantially
higher variation  out there when you get out a of a single admistrative
domain.
> 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 
>