[ntpwg] REQUEST FOR TEXT - Protocol Doc Changes

[rich.osman at nsn.com]

David, 

The goal here is to provide a description that prevents divergence
caused by inconsistent ad-hoc extension the standard in hardware. There
are many hardware "NTP" solutions available and more coming that make
IEEE1588-like performance claims.  The goal here is to define a
parameter that permits interoperability and prevents incompatible
extension.  Well that, and get the conversation started since it seems
like this is the last open issue. 

The argument that we "can't do this which current hardware an NICs" is a
plea to freeze any hardware progress.  If we didn't discuss anything
wasn't possible with current implementations, most standards and RFCs
wouldn't exist.  While you can argue that might be a good thing in a
large number of cases, the reality is that hardware can gain substantial
benefits from early agreements on standard functions. 

Other comments inline...

> -----Original Message-----
> From: ntpwg-bounces+rich.osman=nsn.com at lists.ntp.org 
> [mailto:ntpwg-bounces+rich.osman=nsn.com at lists.ntp.org] On 
> Behalf Of ext David L. Mills
> Sent: Monday, November 12, 2007 10:31 PM
> Cc: ntpwg at lists.ntp.org
> Subject: Re: [ntpwg] REQUEST FOR TEXT - Protocol Doc Changes
> 
> Karen,
> 
> As engineering principle, the only really accurate timetag is the SOF 
> octet, which 1588 uses. 

You are of course correct, but this then requires that the definition
then be aware of the media and protocol as you observe.  I'd suggested
this as a compromise between the simplicity and performance.  If we need
to define this for each media and protocol the appendix will soon be
much larger than the base document. 

> Using any other octet is not a good 
> idea, as it 

There is no question that the first bit is the best choice, but I think
"not a good idea" is a bit strong as it implies catastrophic results.
What I'm suggesting is a compromise for the sake of simplicity that
limits the ultimately achievable accuracy in a slight way.  Well that
and to foster exactly this kind of discussion from the interested
parties. 

> could be affected by coding in some technowledgy as well as 

This is pretty speculative.  Intervening high speed radio and optical
networks may do this, but their effect on the reconstituted packets
should be barely observable over the packet in a working system (in any
real cases.) The server and client interfaces will be some flavor of
Ethernet in the vast majority of cases.  The remaining interface options
are unlikely to use complex coding schemes that generate observable
artifacts for which substantial compensation is impossible.  That is, it
should be possibly to mostly compensate for those effects. 

> jitter and 
> clock skew. My best example why this is really the only 
> choice is space 
> links, which get heavy duty coding. The issue then is where is that 
> precious octet you want to find in the midst of interleaved, 
> convolutional coding? 

I realize that this is an extreme example to illustrate your point.
It's nowhere and everywhere - that's effectively the point of the coding
scheme, spread the energy of each bit over as much of the message as
possible to limit impact of an error on that bit's energy. But what's
the point?  We would not be dealing with this heavily coded data stream,
we'll be dealing with the decoded result and include the coder and
decoder jitter and artifacts in the errors that get filtered. 

If we make a compromise choice, the advantages and limitations should
become well known and documented, and system designers will need to
consider them as they do today in all system design.  

> I recommend we specify the timetag point as a 
> media and protocol issue, perhaps in an annex.

My concern with this approach is that it is high order overkill and
poison pill to any action. It will explode the size of the RFC with only
marginal advantage gained. If anything, it might be that we specify it
for IPv4 and IPv6 and ignore the underlying media concerns. This was my
first thought, but I figured that would be higher impact than was
intended or achievable. 

Rich