[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamp location

[STUART VENTERS]

Dave,


Life is pretty good, we are generally in agreement on the 1st and 3rd paragraph and the 2nd may have gone from futile to only un-necessary.

Let me try a scenario based on my understanding of your second paragraph and see where we end up.

Say the NTP spec turns out like you want and an implementer (named Herbie Worker) takes it and builds an NTP client and server.  He's building in an fpga and decides to strike timestamps when the start of each packet enters and exits his host.  (IE scarfed on the wire at SOP.)  He's careful and his timestamps have variances on say 40ns.  Furthermore, he decides to use the same timestamping design at both the client and server.  This makes guaranteeing the reciprocal match automatic, since each direction passes a packet through identical time strikers.  He gets it all running and installs test wires on the time counters at the client and server.  From the test points, he notes that on a point to point link the client is time aligned to the server within 40ns.  Herbie has successfully built a rigorous NTP implementation and he is a happy camper.  Marketing looks at the tests and decides to sell an NTP implementation with an advertised accuracy of 40ns.

Another implementer (named Sue Worker) also decides to build an NTP client and server from the spec.  She's doing it in software, but has a dedicated fast processor and after thinking about it decides to strike timestamps as close to the hardware as she can which is in her drivers.  (IE scarfed in the drivers.)  She's pretty sharp and figures out that with a wire between the RX interrupt and her Hardware timers, she can timestamp incoming packets to within 100ns.  She also figures out that by waiting until the transmitter is quiet before starting a packet, she can control the timestamp outgoing packets to within 100ns.  She also has testpoints and her client is aligned to her server within 100ns.  Sue has successfully built a rigorous NTP implementation an we have another happy camper.  Marketing looks at the tests and decides to sell an NTP implementation with an advertised accuracy of 100ns.

A third guy (named Pesky User) decides to do some time keeping and builds a system using Herbie's server and Sue's client.  He does so and notices a time offset of a few microseconds.  This seems contrary to the specs, what's wrong?  One answer is that Pesky, by plugging together 2 stunning NTP implementations, essentially constructed a third NTP implementation, but without enough rigor to ensure that the reciprocal delays match.  

Pesky finds this answer unsatisfying, (after all, he's a user not an implementer), and so the IETF reopens the NTP spec.  The new spec affirms Herbie's choice and Sue adds a minor compensation factor to bring her implementation into compliance.  Now Pesky can plug different implementations together at will.  Everybody is happy except for the users with islands of Sue's original implementation.


Ideally there is something wrong with my scenario or in my understanding of what you are saying.  I'd be perfectly happy to be wrong if there is a simpler way to make a complete spec.  

If not, then IMHO, the NTP spec still needs tell Herbie and Sue that they have to assure a reciprocal delay match. Since there are multiple non-interoperable ways of doing so (for example the 2 above), it also needs to give them a clue as to which one to use.  I don't pretend to know the best way to do this, but nailing down CP1 and CP2 is a possibility.


Regards,

Stuart



ps, It's possible that the reason we are here is that this is the first time that it's become reasonable to implement NTP to a degree of accuracy where this sort of precision in the spec matters.

pps,  It seems to me that NTP may already be superior to 1588 in precision timekeeping applications where the packets have to go through vanilla packet switches.  It this case more measurement packets means better odds of getting a lucky one.  The followup packets are a hindrance to more measurement packets.  (Unless the followup packets are also measurement packets, or you build a 1588 implementation which doesn't need/use followup packets.)