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

From: Nalini Elkins <[email-masked]>
Date: Wed, 16 Oct 2013 20:25:05 -0700 (PDT)

All,

I have revised the 6man submission to take out the calculations and packet flows.  All of these are in the IPPM document.   A notation of all the usage cases that this methodology should handle has also been added to the IPPM draft.

The IPPM draft is here: http://datatracker.ietf.org/doc/draft-elkins-ippm-pdm-metrics/

The 6man draft is below.

I appreciate any thoughts and comments.

A new version of I-D, draft-elkins-6man-ipv6-pdm-dest-option-04.txt
has been successfully submitted by Nalini Elkins and posted to the
IETF repository.

Filename:     draft-elkins-6man-ipv6-pdm-dest-option
Revision:     04
Title:         IPv6 Performance and Diagnostic Metrics Destination Option
Creation date:     2013-10-16
Group:         Individual Submission
Number of pages: 12
URL:             http://www.ietf.org/internet-drafts/draft-elkins-6man-ipv6-pdm-dest-option-04.txt
Status:          http://datatracker.ietf.org/doc/draft-elkins-6man-ipv6-pdm-dest-option
Htmlized:        http://tools.ietf.org/html/draft-elkins-6man-ipv6-pdm-dest-option-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-elkins-6man-ipv6-pdm-dest-option-04

Abstract:
   To diagnose performance and connectivity problems, metrics on real
   (non-synthetic) transmission are critical for timely end-to-end
   problem resolution. Such diagnostics may be real-time or after the
   fact, but must not impact an operational production network. The base
   metrics are: packet sequence number and packet timestamp.  Metrics
   derived from these will be described separately. This document solves
   these problems with a new destination option, the Performance and
   Diagnostic Metrics destination option (PDM).

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ray Hunter <[email-masked]>
Date: Sun, 20 Oct 2013 14:07:31 +0200

> until the htmlized version and diff are available at tools.ietf.org.

Given that it seems to me that:

1) encoding has to be fast, but decoding does not
2) a node's clock could be either in our out of synch with some notional
master clock (e.g. via NTP)
3) two clocks could be in synch to a master source, but the master
sources may themselves not share a common source (one sourced from GPS,
one from DCF77)
4) the key to being able to perform the end to end calculations is
whether two communicating nodes are synchronised to the same master
clock (within some level of error/jitter)
5) the absolute time is not particularly important

Q1. Why do you want to encode differences as deltas in the case of an
unsynchronised/ free running clock?

Isn't that slow, and difficult for hardware implementations to achieve
(e.g. TCP offload)?
Doesn't it also require maintaining large amounts of state in the
sending node.
 
Why not just encode the timestamp as-is and perform the appropriate
difference calculation during decoding?

Q2. Why do you need two separate packet formats at all?

Why not have a common format for all cases, containing a timestamp based
on the local clock, plus an optional field containing a flag that states
if the local timestamp is coordinated to some master clock, plus an
identifier for the master clock.

You could then encode whether a node had a free-running clock (case 2),
a synchronised clock (case 1), and whether it was synched via NTP to
some stratum 0 source e.g. GPS, and also some identification of the
stratum 1 source (IPv6 address).

Two communicating nodes could then use e.g. NTP trace to see if they
shared a common clock source or not, before performing their calculations.

IMHO that would then allow you to place some error bounds on your time
calculations, whilst also simplifying the implementation for the sender.

-- 
Regards,
RayH

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 21 Oct 2013 15:58:20 -0700 (PDT)

> 1) encoding has to be fast, but decoding does not

True

>5) the absolute time is not particularly important

This is true for PDM 1 only.  PDM 2 does not require time synchronization.

> Q1. Why do you want to encode differences as deltas in the case of an unsynchronised/ free running clock?
> Isn't that slow, and difficult for hardware implementations to achieve (e.g. TCP offload)? Doesn't it also require maintaining large amounts of state in the sending node.
>

1. I think that it is going to be interesting to see how hardware is going to handle TCP offload with IPv6 extension headers.   I do not see why PDM 2 would be so much harder than PDM 1 for an OS.
Can you tell me which end host operating systems are doing TCP offload in hardware?   

I know some OS's which process TCP segmentation in hardware.    But at this point, the packet is already crafted.  Also some do IP checksum offload in hardware but that does not apply to IPv6 as there is no IP header checksum.

2.  End hosts already maintain quite a bit of state.  Every OS has control blocks to handle events such as TCP duplicate packets, round trip time, congestion window, etc.   We are NOT suggesting
that the PDM headers be used in middle boxes.  That is, we are NOT asking routers to maintain state.

> Why not just encode the timestamp as-is and perform the appropriate difference calculation during decoding?

If clocks are out of synch, you could end up having it look like you received the packet before you sent it.

>shared a common clock source or not, before performing their calculations.

We are trying to craft a solution with PDM 2 for those situations where time synchronization is not practical, possible or desired.

---

From: Ray Hunter <[email-masked]>
Date: Tue, 22 Oct 2013 08:10:12 +0200

> Nalini Elkins <mailto:[email-masked]>
> 22 October 2013 00:58
IMHO Not a relevant question. As a standards body we should be looking
to the future. There are many operations that are delegated to microcode.

If you specified the packet with one single way of encapsulating
timestamps, then hardware or interface microcode could add the timestamp
at the last possible moment before the packet reached the wire, without
having to examine the original packet contents, or knowing the context
of the communicating nodes. I think that's very desirable.
> that the PDM headers be used in middle boxes.  That is, we are NOT asking routers to maintain state.
So what? Why add to the problem?

Why does the timestamp require synchronisation with that other TCP state?

Isn't it better to define a solution that is independent of the upper
layer header transport protocol?

<heresy>  Why not allow middleboxes (or node hardware) to insert the
timestamp header on the fly?</heresy>
> If clocks are out of synch, you could end up having it look like you received the packet before you sent it.

No. I'm not suggesting you use the same decoding algorithm: only that
you define a single common encoding algorithm that combines all the
information required for PDM 1 and PDM 2 calculations. Having to chose
which packet encoding to use in advance is problematic IMHO.

> We are trying to craft a solution with PDM 2 for those situations where time synchronization is not practical, possible or desired.

I understand the aim, but let me ask my question a different way.

Imagine there are nodes A&B that with clocks synched to DCF77.
Imagine there are nodes C&D that with clocks  synched to GPS.
Node E has free running clock (possibly because the GPS receiver is down).

Which packet format PDM type 1 or PDM type 2 do you use between each
pair of nodes, and how does the sending node know that?

Scale this solution to 100K hosts.
>
> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: Nalini Elkins <[email-masked]>
Date: Tue, 22 Oct 2013 19:47:40 -0700 (PDT)

>of the communicating nodes. I think that's very desirable.

Sure.   Sounds good!  Also looking to the future, then I will speculate that we will likely have more and better time synchronization also.

>So what? Why add to the problem?

Yes.  Just saying that we are not CREATING the problem.

>Why does the timestamp require synchronisation with that other TCP state?

It doesn't.  Just mentioning other reasons why state is maintained.

>Isn't it better to define a solution that is independent of the upper layer header transport protocol?

Yes.  Our solution IS independent.  I think my analogy actually confused the issue!

><heresy>  Why not allow middleboxes (or node hardware) to insert the timestamp header on the fly?</heresy>

Interesting idea!

> No. I'm not suggesting you use the same decoding algorithm: only that you define a single common encoding algorithm that combines all the information required for PDM 1 and PDM 2 calculations. Having to chose

We will look at this.   I am also meeting with a couple of the end host OS vendors to get their viewpoint on the PDMs.   Their engineers have good opinions on what the problems might be with actually creating PDMs.
I should have that info before Vancouver.

>Scale this solution to 100K hosts.

Good question.  We were thinking that each node would start with PDM 1 and then if the other side could not do PDM 1, then it would drop back to PDM 2.
But, the clock issue is good.  Now, my understanding is that clock difference has more to do with Stratum levels.    But, I am not the NTP expert in the group. 
I am just wondering (leaving off Node E) how much clock difference would there be?   What do you think? I have a meeting with my team tomorrow & will bring this up for discussion.

-- 
Regards,
RayH

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 24 Oct 2013 16:50:01 +0000

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.   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?

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? 

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!  

Again, thanks for your great input, thoughts and questions!!!  (and hopefully more to come).  

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ray Hunter
Sent: Tuesday, October 22, 2013 2:10 AM
To: Nalini Elkins
Cc: v6ops WG; 6man WG; [email-masked]
Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt

>>  2) a node's clock could be either in our out of synch with some 
>> notional  master clock (e.g. via NTP)
>> sources may themselves not share a common source (one sourced from 
>> GPS, one from DCF77)
IMHO Not a relevant question. As a standards body we should be looking to the future. There are many operations that are delegated to microcode.

If you specified the packet with one single way of encapsulating timestamps, then hardware or interface microcode could add the timestamp at the last possible moment before the packet reached the wire, without having to examine the original packet contents, or knowing the context of the communicating nodes. I think that's very desirable.

> If clocks are out of synch, you could end up having it look like you received the packet before you sent it.

No. I'm not suggesting you use the same decoding algorithm: only that you define a single common encoding algorithm that combines all the information required for PDM 1 and PDM 2 calculations. Having to chose which packet encoding to use in advance is problematic IMHO.

>>  Why not have a common format for all cases, containing a timestamp 
>> based on the local clock, plus an optional field containing a flag 
>> that states if the local timestamp is coordinated to some master 
>> clock, plus an identifier for the master clock.
>
>> You could then encode whether a node had a free-running clock (case 
>> 2), a synchronised clock (case 1), and whether it was synched via NTP 
>> to some stratum 0 source e.g. GPS, and also some identification of 
>> the stratum 1 source (IPv6 address).
>

Which packet format PDM type 1 or PDM type 2 do you use between each pair of nodes, and how does the sending node know that?

--
Regards,
RayH

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

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.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 24 Oct 2013 19:51:54 +0200

> Ackermann, Michael <mailto:[email-masked]>
> 24 October 2013 18:50
> Hi Ray.
> 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.  
Absolutely. Different NTP servers are not guaranteed to be synched to
each other. They're close. But not in the picosecond range.
> 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 perc…

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…
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).  
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

---

From: joel jaeggli <[email-masked]>
Date: Thu, 24 Oct 2013 11:14:35 -0700

> Your point 4 seems to indicate that all nodes in a desired time synchronization domain need to be synched to the same master clock.   This has not been my experience.   As long as the required Stra…

stratum is not an indication of either precision or accuracy it’s an inidication of a position within the NTP heirachary.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 24 Oct 2013 23:44:51 +0000

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:[email-masked]] 
Sent: Thursday, October 24, 2013 1:52 PM
To: Ackermann, Michael
Cc: Nalini Elkins; v6ops WG; 6man WG; [email-masked]
Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt

> 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 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 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.
> 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 perc…

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…
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).  
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

---

From: Ray Hunter <[email-masked]>
Date: Fri, 25 Oct 2013 19:38:09 +0200

> 25 October 2013 01:44
No. We are not in agreement.

Stratum is an indication of how far down you are in the hierarchy from
any NTP Stratum 0 clock.

It says nothing about whether your stratum 0 and my stratum 0 are
synchronised.

We could both be running caesium clocks, and there could still be an
offset if I don't set my reference time of my caesium clock the same as
your reference time. When talking about microsecond or picosecond timing
that will almost certainly be significant.

You really need to know that the true provenance of the clock source is
identical in order to make PDM 1 calculations, not just the stratum.

Hence my comment to couple some sort of "clock ID" to the timestamp.

---

From: Nalini Elkins <[email-masked]>
Date: Sun, 27 Oct 2013 07:59:10 -0700 (PDT)

> >Your point 4 seems to indicate that all nodes in a desired time synchronization domain need to be synched to the same master clock.  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.  

>stratum is not an indication of either precision or accuracy it’s an inidication of a position within the NTP heirachary.

Guys, you know, I wonder if this discussion of time synchronization is distracting us from the point of our proposal.   

What we are advocating for is a capability for embedded diagnostics and performance for all upper layer protocols that is relatively simple to implement.   I am thinking more and more that our PDM 2 proposal which does not require time synchronization is the way to go.   Let me say that this is my opinion only!   Others on our team believe that they can indeed do time synch within their data centers and want the enhanced capabilities of PDM 1 which requires time synch.

BTW, we have discussed the proposals for PDMs already with one end host OS vendor who, on initial look, believes it will be easy to implement and should be quite useful.   We are setting up more discussions with their engineering team to see if they can tell us where the pit falls in our thinking might be.   I hope I can get them to comment publicly.   But, that will take a while.

Also, one of my guys has already done a prototype implementation of PDM 1 going from a simple client to server which I can show all who are interested in Vancouver.   

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 28 Oct 2013 16:13:13 +0000

Hey Ray

It appears your experiences with Time Synch and Stratum levels are different than mine.   In the older Telecom and Voice World Stratum was a great indicator of clocking accuracy.   Still is as far as I know.   This was always true with or without NTP in the picture.   
And whenever we had two Stratum 0's or 1's, be they the same or different masters, they WOULD be in synch.   We never had a situation that was an exception to that, with or without NTP.  

Thanks

Mike

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

Stratum is an indication of how far down you are in the hierarchy from any NTP Stratum 0 clock.

It says nothing about whether your stratum 0 and my stratum 0 are synchronised.

We could both be running caesium clocks, and there could still be an offset if I don't set my reference time of my caesium clock the same as your reference time. When talking about microsecond or picosecond timing that will almost certainly be significant.

You really need to know that the true provenance of the clock source is identical in order to make PDM 1 calculations, not just the stratum.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 28 Oct 2013 12:24:03 -0400

Hi Michael.

On 10/28/13 12:13 PM, Ackermann, Michael wrote:
> Hey Ray
> 
> It appears your experiences with Time Synch and Stratum levels are
> different than mine.   In the older Telecom and Voice World Stratum
> was a great indicator of clocking accuracy.   Still is as far as I
> know.   This was always true with or without NTP in the picture. And
> whenever we had two Stratum 0's or 1's, be they the same or different
> masters, they WOULD be in synch.   We never had a situation that was
> an exception to that, with or without NTP.

The NTP definition of stratum is different from that used in the
telecommunications domain.  The primary feature of a NTP stratum 0 clock
is the ability to generate accurate pulse per second signals, hence
calling them reference clocks.  It should be noted that in NTP, stratum
0 clocks are *not* NTP servers, they are the source of time information
to stratum 1 servers that serve time via NTP.

Regards,
Brian

---

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 28 Oct 2013 16:49:21 +0000

Thank you Brian.

What you say matches my understanding and experiences

-----Original Message-----
From: Brian Haberman [mailto:[email-masked]] 
Sent: Monday, October 28, 2013 12:24 PM
To: Ackermann, Michael; Ray Hunter
Cc: v6ops WG; 6man WG; [email-masked]
Subject: Re: [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt

Hi Michael.

> an exception to that, with or without NTP.

The NTP definition of stratum is different from that used in the telecommunications domain.  The primary feature of a NTP stratum 0 clock is the ability to generate accurate pulse per second signals, hence calling them reference clocks.  It should be noted that in NTP, stratum
0 clocks are *not* NTP servers, they are the source of time information to stratum 1 servers that serve time via NTP.

Regards,
Brian

---

From: joel jaeggli <[email-masked]>
Date: Mon, 28 Oct 2013 10:06:44 -0700

> What you say matches my understanding and experiences

Then you should revise your statement accordingly…

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 28 Oct 2013 10:18:33 -0700 (PDT)

Joachim,
 
Thanks very much.  We will take a look and revise the drafts accordingly.

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Joachim Fabini <[email-masked]>
To: "Ackermann, Michael" <[email-masked]>; Ray Hunter <[email-masked]> 
Cc: v6ops WG <[email-masked]>; 6man WG <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, October 28, 2013 9:40 AM
Subject: Re: [ippm] [v6ops] Fw: New Version Notification for draft-elkins-6man-ipv6-pdm-dest-option-04.txt

Mike, Nalini,

please have a look at http://tools.ietf.org/html/rfc2330#section-10 
and/or http://tools.ietf.org/html/rfc5905 for a detailed technical 
discussion on time issues/NTP. With respect to these parameters, the 
term "in sync" which you use is _purely_ theoretical and must be 
consolidated to a technical specification in terms of RFC2330 clock 
parameters (accuracy, resolution, etc.) to be usable in practice. I 
think this is what Ray meant. Stratum per se (in the NTP sense) is imho 
misleading/useless as a quality indicator.

regards
Joachim

Am 28.10.2013 17:13, schrieb Ackermann, Michael:
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Joachim Fabini <[email-masked]>
Date: Mon, 28 Oct 2013 17:40:13 +0100

Mike, Nalini,

regards
Joachim

---

From: Cutler James R <[email-masked]>
Date: Mon, 28 Oct 2013 12:57:36 -0400

> And whenever we had two Stratum 0's or 1's, be they the same or different masters, they WOULD be in synch.   We never had a situation that was an exception to that, with or without NTP.  

Before getting too deep into this particular argument, it would be good to review documents at http://www.eecis.udel.edu/~mills/ntp.html and ntp.org.  

When discussion time synchronization using NTP, stratum refers to the distance from reference clock.  Accuracy is separately a function of reference clock and there are many variants of reference clock.  That two systems are “in synch” is the magic of NTP algorithms and is orthogonal to accuracy.

James R. Cutler
[email-masked]