Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt

[Ray Hunter <[e-mail]>]

> Ackermann, Michael <mailto:[e-mail]>
> 24 October 2013 18:50
> Hi Ray.
> And thanks again for all your insightful comments/questions. 
>
> I am a little late in responding, so let me just tack on a little to what Nalini and others have already said. 
>
> Your point 4 seems to indicate that all nodes in a desired time synchronization domain need to be synched to the same master clock. 
No. I think what I said was that the level of certainty in your
measurements is dependent on the level of synchronisation of the 2 clock
sources if you are calculating a delta of timestamp of clock 1 -
timestamp clock 2.

I think it might be instructive to go back and look at high school
physics books on making measurements, precision, accuracy, and error
estimations, especially when taking the difference of two measurements,
or making other calculations on top of raw observations.

For example, as far as I know, DFC-77 is not compensated for speed of
light travel time from Frankfurt: that is a manual offset. So even if
two nodes using DCF-77 that are geographically spread across Europe are
perfectly synchronised to the incoming radio signal, they might have a
constant offset compared to the "absolute" time in Frankfurt. That may
or may not have an effect on one way trip measurement times you measure,
depending on how you perform your calculations.

I think this link might be instructive.
http://www.hopf.com/en/dcf77-gps_en.html

Equally a stratum 0 clock can be free running if it loses it's radio signal.

I see time stamps in the picosecond range defined in the protocol, and
errors on DCF-77 of up to 150mS...... completely different orders of
magnitude of precision.


>   This has not been my experience.   As long as the required Stratum level is realized, for the level of accuracy required by the situation or application, the proper level of time synchronization is achieved.   Example would be that if one node in the NTP domain is referencing a GPS Stratum 0 and another node is referencing a separate Stratum 0 source, the two nodes should be Stratum 1 and within that level of accuracy.  
> This is something we have implemented across several disparate enterprises and it has worked well for us.  I am wondering if your experience has yielded different results?
Absolutely. Different NTP servers are not guaranteed to be synched to
each other. They're close. But not in the picosecond range.
> You also had two other points/questions, that I believe Nalini already responded to, but..............
>
> 1. The possibility that "Middleboxes" could utilize PDM, is very intriguing to me.  I believe this would be more difficult to add/implement, but worth the effort if the Middlebox vendors would perceive value and actually use PDM.  Not sure how to determine if this would be the case or not? 

Why would it be difficult? If you can define the encoder in your
protocol in terms of absolute local timestamps only, plus a provenance
of the clock used for the timestamp, it would be a simple matter of
inserting an additional destination header into every forwarded packet
when the middlebox forwards it.
> 2. It would be ideal to have only 1 PDM format that handles both time sycnronized and non synchronized situations.   I do not readily see how to achieve this.   Would love to talk to you some more if you have some ideas!  
Well for example, PDM 2 uses a local delta for the last packet
transmission time: DELTALS.

IMHO If you know absolute timestamp 1 of clock 1 @ last packet n sent
from node 1, and absolute timestamp 2 of clock 1 @ last packet n+1 sent
from node 1, I see it as a trivial matter to calculate the delta time
between sending packet n and sending packet n+1 remotely at a decoder at
a remote location (as observed at node 1), which will be identical to
DELTALS, rather than calculating this value locally in the transmitting
node 1 before sending the packet. [you can only encode this DELTALS
value in packet 2.. anyway]

I suspect the step that you are missing is coupling a timestamp to a
clock and a packet ID and an event, and specifying only two timestamps
in the packet, rather than both nodes timestamping the same events with
their respective local clocks.

You could also have timestamps for last received n from node 2 based on
clock 1 sent in replies to packet n by node 1, and last received n+1
from node 2 based on clock1 sent in replies to packet n+1 by node 1, so
that you can calculate DELTALR remotely too (as observed at the location
of the receiving node 1). That way you avoid the need to calculate delta
locally, or any need to track sessions in the transmitter (so that you
can calculate a delta in the transmitter). You do obviously have to
calculate a delta and track sessions in the decoder, but that is not
time critical, and also can be applied to a subset of all traffic.
>
> Again, thanks for your great input, thoughts and questions!!!  (and hopefully more to come).  
>
> Mike
>
It seems to me that what you are essentially doing with this protocol is
largely what NTP does anyway.

So examining the NTP RFC might give you tips on what timestamps you
need. And equally, since you are going to be sending high bandwidth
synch traffic between 2 nodes, you might want to consider feeding the
results back into NTP to see if you can improve the clock
synchronisation between measuring nodes.

-- 
Regards,
RayH