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

["Ackermann, Michael" <[e-mail]>]

Ray

Your Comment: 
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.
My Response:
Then it sounds like we are in agreement.   Given the appropriate stratum level at both nodes, the desired level of time synchronization is achieved. 


Your Comment: 
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
My Response:  Not sure exactly what this means but I can say that this sounds like theoretical doubt that time synchronization will not work properly in geographically dispersed environments?    I can tell you that it does in our experiences and that the surrounding protocols/implementations are crafted to account for such vicissitudes.  
I will say that I have no field experience with DCF-77 sources, only GPS and Cesium.  


Your Comment:
Equally a stratum 0 clock can be free running if it loses it's radio signal.
My Response: 
This comment sort of confused me as well, but suffice to say, if any component is broken, results will be impaired.   Obviously this is not limited to the time synch subject.  


Finally, your comment about "Middleboxes".    I hope it can be as simple to accommodate as you describe.   My concern is that if there are numerous middleboxes, the fields may get repetitively overlaid, or there will need to be so many separate fields, we could incur excessive complexity or overhead.    Given that we can accomplish this with a workable solution, I am certainly all for it.   
The more information I can have to manage networks and solve problems, the better!

Thanks again for your thoughts, inputs and questions!

Mike









 





-----Original Message-----
From: Ray Hunter [mailto:[e-mail]] 
Sent: Thursday, October 24, 2013 1:52 PM
To: Ackermann, Michael
Cc: Nalini Elkins; v6ops WG; 6man WG; [e-mail]
Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt

> 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



The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.