Subject: [ntpwg] REQUEST FOR TEXT - Protocol Doc Changes

From: Jim Martin <[email-masked]>
Date: Thu, 8 Nov 2007 13:47:04 -0800

Gentlepeople,
	Based upon the notes (and my recollection) from the meeting in  
Chicago, there were four  main points to be addressed in the next (and  
hopefully final) rev of the protocol spec.  They were:

> Comments/Questions from Floor:
>
> Mark Townsley concerned with usage of the term "private networks"
> in resolving Stewart Bryant comments
> * Proposal to use stratum (i.e. a different stratum level) as a  
> protection mechanism
> * Tim Sheppard proposed use of port number
> * Yakov proposed using a field in header that could be used as  
> indicator
> * Karen proposed to modify text (eliminate reference to private  
> networks)
> to remove issue
> *The consensus was that the term "private networks" will be removed  
> from draft
	This has been done. Specifically, the text in Section 2, "Modes of  
Operation" has been changed from:

"Alternative algorithms MAY be used, but their output MUST be  
identical to the algorithms described in this specification, or they  
MUST be used exclusively in a private network."

to

"Alternative algorithms MAY be used, but their output MUST be  
identical to the algorithms described in this specification."
>
> -Comment from Tony Hain, refid should not be associated with IP  
> address
> *Jim believes that text in draft is OK
> *It was agreed that this will be verified
  	Tony was concerned that this was a v4 only dependancy. As seen in  
the following quote from the text, that's not the case. No change  
required.

"Above stratum 1 (secondary servers and clients) this is the reference  
identifier of the server and can be used to detect timing loops. If  
using the IPv4 address family, the identifier is the four-octet IPv4  
address. If using the IPv6 address family, it is the first four octets  
of the MD5 hash of the IPv6 address."

> -Comment from Stewart Bryant:  need to specify precisely the start bit
> * Yakov and Stewart Bryant agreed to contribute text to resolve this  
> issue

	This is where I'm looking for input from the community. Yakov,  
Stewart, Rich Osman, or anyone who has a good grasp on the issue and  
can generate a few lines to precisely characterize the details.  This  
is currently the blocker on getting this out.

>
>
> -Discussion regarding IANA
> * The group consensus was that the group needs to precisely identify
> items that are to be IANA Managed
> *Need to identify and articulate policies
	I'm currently in the process of going through the document and  
identifying which code points make sense to pull out and put under  
IANA control.  If anyone wants to take a pass through and give me  
their opinion of what needs to move into the IANA considerations, I'd  
appreciate it, but if not, I'll just go ahead with my best estimate.

- Jim

_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Jim Martin <[email-masked]>
Date: Thu, 8 Nov 2007 14:30:08 -0800

On Nov 8, 2007, at 1:47 PM, Jim Martin wrote:
> their opinion of what needs to move into the IANA considerations,  
> I'd appreciate it, but if not, I'll just go ahead with my best  
> estimate.

	After a pass through the document, I believe that the only three  
things that make sense to put under IANA management are the refid,  
kiss-o-death codes, and extension field types. The currently published  
version of the document already has the KOD codes and extension field  
types being managed, so I'm proposing to make the following addition  
to the IANA considerations section:

>    The IANA is requested to create a new registry for NTP Reference
>    Identifier codes.  This should include the current codes defined in
>    Section 7.3, and may be extended on a FCFS basis.  The format of  
> the
>    registry is:
>
>
>      +------ 
> +----------------------------------------------------------+
>      | ID   | Clock  
> Source                                             |
>      +------ 
> +----------------------------------------------------------+
>      | GOES | Geosynchronous Orbit Environment  
> Satellite               |
>      | GPS  | Global Position  
> System                                   |
>      | ...   
> | ...                                                      |
>      +------ 
> +----------------------------------------------------------+
>
>                    Figure 35: Reference Identifier Codes
>

	Also, I'm considering further modifying the text for both the refid  
and KOD codes to define that any KOD or refid that begins with "X" is  
experimental, available for unregistered experimentation, and MUST be  
ignored if unknown.  Opinions?

	PLEASE yell if you see any other values that should go under IANA  
management!

	- Jim

---

From: Danny Mayer <[email-masked]>
Date: Mon, 12 Nov 2007 00:23:49 -0500

> of the MD5 hash of the IPv6 address."

This is the current practice in the NTP reference implementation but it
is not required to be. It could, for example be the first 4 octets of
the MD5 hash of the MAC address. Anything may be used as long as it's
consistent.

> is currently the blocker on getting this out.

It would help to know what start bit you are talking about. I have no
idea. Does someone have a reference to a section of the draft?

Danny

---

From: <[email-masked]>
Date: Mon, 12 Nov 2007 20:20:41 -0600

> -----Original Message-----
> From: ntpwg-bounces+rich.osman=[email-masked] 
> [mailto:ntpwg-bounces+rich.osman=[email-masked]] On 
> Behalf Of ext Jim Martin
> Sent: Thursday, November 08, 2007 3:47 PM
> To: [email-masked]
> Subject: [ntpwg] REQUEST FOR TEXT - Protocol Doc Changes
> 
> Gentlepeople,

 <stuff deleted>

> is currently the blocker on getting this out.

NTP has a lot in common with IEEE-1588 and there can be value in
consistency if it isn't foolish. 

IEEE P1588 D2.2 paragraph 7.3.4.1 "Event message timestamp point" says:
"Unless otherwise specified in a transport specific Annex to this
standard, the message timestamp point for an event message shall be the
beginning of the first symbol following the start of frame delimiter."

I'd propose that the leading edge of the first bit of the LI Leap
Indicator (first transport independent point) of the NTP packet header
as shown in Figure 8 be the reference point.  This isn't completely
consistent with 1588, but I believe it's consistent with the intent and
with the rest of NTP. Regardless of where it ends up, it should be in
the first 12 words of the message so that there is no need to compensate
for varying message lengths.  A brief look at some sample code seems to
indicate that this is about the location that assumed but I've done no
exhaustive or scientific search.

Given the structure of the document I believe that the end of section 4
"Definitions" is probably the best place to include the text: "The
timestamp reference point is the leading edge of the first bit of the LI
Leap Indicator bit pair of the NTP packet header shown in Figure 8."

--

Rich Osman
Nokia Siemens Networks
mailto:[email-masked]
6000 Connection Drive; Irving, TX  75039

---

From: "Odonoghue, Karen F CIV NSWCDD, W13" <[email-masked]>
Date: Mon, 12 Nov 2007 20:38:33 -0600

Just out of curiosity, if there isn't a strong rationale to differ from 1588 why would we do so. Part of the point of this would be to potentially leverage hardware in the future. If 1588 and 802.1AS define the same timestamp point, why would we differ?
 
Karen

________________________________

From: ntpwg-bounces+karen.odonoghue=[email-masked] on behalf of [email-masked]
Sent: Mon 11/12/2007 8:20 PM
To: [email-masked]
Subject: Re: [ntpwg] REQUEST FOR TEXT - Protocol Doc Changes

 <stuff deleted>

--

Rich Osman
Nokia Siemens Networks

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 13 Nov 2007 04:05:10 +0000

Karen,

With all due respect, we don't get to do this with current operating 
systems and NICs. All we can do is retrieve the kernel time after 
receiving a packet and before sending a packet. The operating system 
doesn't know when the first octet (SOF) of the frame arrives or departs 
unless the NIC tells it so, which is what 1588 hardware does. Even with 
1588 we can't infer when any particular octet within the packet was sent 
or received unless we know icky details about the bit rate, etc.

Dave

Odonoghue, Karen F CIV NSWCDD, W13 wrote:

> Just out of curiosity, if there isn't a strong rationale to differ 
> from 1588 why would we do so. Part of the point of this would be to 
> potentially leverage hardware in the future. If 1588 and 802.1AS 
> define the same timestamp point, why would we differ?
>
> Karen
>
>>> -Comment from Stewart Bryant: need to specify precisely the start
>>
> bit
>
> ------------------------------------------------------------------------
>

---

From: "Odonoghue, Karen F CIV NSWCDD, W13" <[email-masked]>
Date: Mon, 12 Nov 2007 22:10:34 -0600

That's true for today; however, the discussion at the meeting was more along the lines of if someone in the future built hardware that could do this, they would need to know what point was the "transmission event". Currently, this is an estimate based on the issues you mentioned, but it could be more precise in the future. The suggestion was made that we go ahead and specify this. It doesn't impact current implementations, but it does provide some needed specification should someone pursue this approach. Do you think a clarification is needed on the text Rich provided to address this?
 
Karen

From: ntpwg-bounces+karen.odonoghue=[email-masked] on behalf of David L. Mills
Sent: Mon 11/12/2007 10:05 PM
To: [email-masked]
Subject: Re: [ntpwg] REQUEST FOR TEXT - Protocol Doc Changes

Karen,

Dave

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 13 Nov 2007 04:30:34 +0000

Karen,

As engineering principle, the only really accurate timetag is the SOF 
octet, which 1588 uses. Using any other octet is not a good idea, as it 
could be affected by coding in some technowledgy as well as 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 recommend we specify the timetag point as a 
media and protocol issue, perhaps in an annex.

Dave

Odonoghue, Karen F CIV NSWCDD, W13 wrote:

> That's true for today; however, the discussion at the meeting was more 
> along the lines of if someone in the future built hardware that could 
> do this, they would need to know what point was the "transmission 
> event". Currently, this is an estimate based on the issues you 
> mentioned, but it could be more precise in the future. The suggestion 
> was made that we go ahead and specify this. It doesn't impact current 
> implementations, but it does provide some needed specification should 
> someone pursue this approach. Do you think a clarification is needed 
> on the text Rich provided to address this?
>
> Karen
>

---

From: <[email-masked]>
Date: Tue, 13 Nov 2007 06:03:21 -0600

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

> Behalf Of ext David L. Mills
> Sent: Monday, November 12, 2007 10:31 PM
> Cc: [email-masked]
> 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 
> 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 

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 13 Nov 2007 13:44:42 +0000

My first thought was that the timing reference point
should be the first bit of the NTP payload, since
this was within the NTP scope and everything before it
was a variable length.

However on reflection after reading the thread I think
that the only point in the packet that you can rely
on is start of frame, and this is by far the
easiest point in the frame for the receive hardware
to capture and locally timestamp.

The variable number of bits in the datalink header
and the IP header (IPv4/v6) in principle be
corrected because

a) Both transmitter and receive know (at least in
principle) how many there are and can apply corrections

b) If you go through some switching equipment that
changes any of these factors, then in general
the errors introduced by the switching will
be significant compared to this error, although
in principle the switches could correct the timestamp
accordingly as part of some sort of one step
transparent clock.

- Stewart

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 13 Nov 2007 14:12:34 +0000

Rich,

I don't think you are reading my message carefully as an engineer. No 
matter what protocol, no matter what hardware, no matter what media it 
is a very bad idea to nominate any octet in the message except the 
preamble or SOF following the preamble as the time tag. The reason for 
this is very simple. If you want precision and resolution to the 
nanoseconds level, the Ethernet or whatever clock would have to be 
outstanding in order to avoid normal jitter and clock skew during the 
frame itself. In any case, you cannot, even with super hardware, predict 
the precise timing of other octets within the frame due to coding and 
interleaving, especially on space links needing really good timing. This 
is not a question about possible future technology, just an observation 
of engineering principles.

I sense some skepticism here. Please take this issue to other engineerts 
you trust and confirm or deny my position.

Dave

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 13 Nov 2007 14:29:02 +0000

Stewart,

Yes, the switch can cause significant wiggle due to output blocking, 
retransmissions, etc., and that'w why 1588 requires special switches 
which correct for stochastic delays by retiming the clock.

There is another feature of 1588 called the two-step protocol which 
provides the transmit timestamp in a following packet. You may see my 
suggestion to incorporate this in NTP in the architecture briefing on 
the NTP project page linked from www.ntp.org. The resulting protocol has 
much in common with 1588 with the additional feature that it is symmetric.

The two-step protocol seems in principle not hard to implement as long 
as timestamps can be captured by the driver, not necessarily requiring 
1588 NICs. I lay down the challenge, but not necessarily committing my 
own elbowgrease for driver modifications. Much better somebody who knows 
the Unix internals much better than I. I will, however, committ my 
grease to the NTP protocol modifications and support.

Dave

---

From: "TS Glassey" <[email-masked]>
Date: Tue, 13 Nov 2007 08:37:52 -0800

Why not use the XDR model for representing the 'natural' data as it were.

Todd Glassey

---

From: "Mark Elliot" <[email-masked]>
Date: Tue, 13 Nov 2007 10:17:13 -0800

In the comments below, IEEE 1588 timestamps the first data bit of
Ethernet packet.  The start of frame delimiter mentioned below is the
Ethernet start of packet.  So you are time stamping on the leading edge
of the very first data bit of Ethernet packet.  If you wish to have
consistency, and I do, all time packets that are hardware time stamped
should follow the same rule.  

This way the hardware, that does the time stamping, need not be as aware
of the details of the upper layer protocols.  There are problems with
the timestamp being located in the data part of the packet.  For example
when using protocols like IPv6, with extension headers, the location of
the timestamp in the UDP payload would literally be dependent on IPv6
header options used.  The options would vary over time without the
timing protocol's knowledge.  Here again is one of many good arguments
for the Ethernet layer timestamp.

-----Original Message-----
From: ntpwg-bounces+melliot=[email-masked]
[mailto:ntpwg-bounces+melliot=[email-masked]] On Behalf
Of [email-masked]
Sent: Monday, November 12, 2007 6:21 PM
To: [email-masked]
Subject: Re: [ntpwg] REQUEST FOR TEXT - Protocol Doc Changes

> [mailto:ntpwg-bounces+rich.osman=[email-masked]] On Behalf Of 
> ext Jim Martin

 <stuff deleted>

bit

--

Rich Osman
Nokia Siemens Networks