Subject: [ntpwg] draft minutes from Vancouver NTP WG meeting

From: "Odonoghue, Karen F CIV NSWCDD, W13" <[email-masked]>
Date: Thu, 13 Dec 2007 14:22:40 -0600

Folks,

Below are draft minutes from our recent meeting. If you have any
comments 
or corrections, feel free to send them on. Thank you to Malcolm for
drafting 
them and any errors are the result of my edits...

Karen

Draft (13 Dec 2007)
NTP WG Meeting Minutes
1740 - 1950, Monday, December 3, 2007

The meeting was chaired by Karen O'Donoghue and Brian 
Haberman. Malcolm Airst took the minutes and Yaakov Stein 
acted as Jabber scribe. 

The proposed agenda included:
Administrivia                Chairs
NTPv4 Protocol Specification  Martin
          * draft-ietf-ntp-ntpv4-proto-08.txt
- NTP Autokey Specification     Haberman
          * draft-ietf-ntp-autokey-00.txt
- NTPv4 MIB                     Elliott
          * draft-ietf-ntp-ntpv4-mib-02.txt
- NTP server option for DHCPv6  Lourdelet
          * draft-gayraud-dhcpv6-ntp-opt-00.txt
- TICTOC/Future efforts

NTPv4 Protocol Specification (Jim Martin)
Document: draft-ietf-ntp-ntpv4-proto-08.txt. 
Slides: 
Jim has produced another revision of this document in response to 
Chicago and Prague discussions. The following significant changes 
were made:
*	References to private networks for alternative algorithms were 
removed. 
*	The REFID was placed under IANA management. Verified 
that REFID text does address both v4 and v6. 
*	Text is still lacking that clearly defines which bit in the
packet 
the timestamp represents. The WG needs to decide on the 
precise approach. Three options were discussed:  
a) The timing bit be the first bit of the IP packet or  
b) the timing bit be located at the beginning of NTP payload or  
c) Use the start of the Ethernet frame.  
Discussion: The timestamp should reference the start of the 
NTP header. Yaakov Stein, Stewart Bryant, and Greg Dowd to 
work offline and submit proposed text. 
*	KOD timestamp to be defined in draft-09 using the text 
proposed by Danny Meyer on the mailing list. 
*	The WG should identify remaining issues between the NTP 
and Autokey drafts. Then draft -09 can be published and go 
through another Working Group Last Call. 

NTP Autokey Specification (Brian Haberman)  
Document: draft-ietf-ntp-autokey-00.txt. 
Slides: 
*	WGLC began on 11-02-07
*	Only one set of comments initially received (additional 
comments and suggestions by Greg Dowd and Dave Mills 
were missed in the meeting preparation and are not discussed 
here). 
o	There was a proposal to remove the paragraph 
discussing NATs
o	There was also a comment to remove the sentence 
discussing the use of reverse DNS
o	Other minor comments were discussed and adjudicated
*	Next steps: Revise document based on comments. Further 
discussion needed on the draft. NTPv4 can't proceed without 
the Autokey document. 

NTPv4 MIB (Chris Elliott)
Document: draft-ietf-ntp-ntpv4-mib-02.txt. 
Slides: 
*	Minor updates made to document
o	Added optional statistics objects
o	Remaining work includes verifying compliance with 
latest XML MIB template and incorporating the latest 
comments. 
*	Plan to revise document one final time and issue a working 
group last call. Chris indicated that this could be done within a 
week. 

NTP server option for DHCPv6 (Benoit Lourdelet, Richard 
Gayraud)
Document: draft-gayraud-dhcpv6-ntp-opt-00.txt. 
Slides: 
*	Network operators prefer to centrally configure IP services 
through DHCP. DHCPv6 options are added to offer NTPv4 
client configuration. Two new options were added to DHCPv6:  
1) Advertise NTP server locations and  
2) Address public internet and private network requirements
*	Network operators would prefer to configure NTP parameters 
to fine tune NTP traffic vs. clock accuracy. Another concern is 
that a small NTP server become overloaded, causing the risk of 
a catastrophic NTP event. Existing DHCPv4 only uses the NTP 
server address. Additional configuration options are defined in 
the new draft. Suggestions for additional parameters are 
welcome. 
*	Brian Haberman suggested that first, DHCPv6 should emulate 
DHCPv4 capability. A later revision of the document could 
then cover additional capabilities. There was a detailed 
discussion on which NTP parameters to use and if SNTP 
should also be used. 
*	Should the parameters be reworked? Should Autokey be 
included via reference to ID?  Brian Haberman's suggestion is 
to review comments for impact and then publish a revised 
document. The authors agreed. 

TICTOC/Future Efforts (Karen O'Donoghue)
Karen felt that an open discussion in the NTP WG was needed in 
preparation for the TICTOC BOF planned for the next morning. 
There were some basic questions that should be addressed 
including:  
1) Is there more work that needs to be done with NTP;  
2) What is the best way to accomplish this work; and  
3) Can the IETF sustain two timing related working groups in the 
IETF. 

There does appear to be more work that could and should be done 
standardizing NTP. However, there are not any clear compelling 
proposals on the table yet. Additionally, the NTP working group 
has struggled with finishing work based partly on a lack of 
resources and issues around clear design authority. The original 
charter covered NTPv4 and eventual work on NTPv5. Almost 
three years later we're still trying to get NTPv4 completed. NTPv4 
is a moving target since most implementations are based on a 
changing code base. 

Karen stated that perhaps the next generation timing work does not 
belong in the NTP WG given the issues to date. In this case, 
however, where should any NTP follow on work (NTPv5?) reside? 
Greg suggested that the NTP charter should be updated when 
NTPv4 is completed. Many current NTP issues are not actual 
timing related, but rather NTP control issues. The initial focus of 
TICTOC would be on timing. Yaakov stated that IETF 
Management is concerned that there is not enough critical mass to 
support two WGs covering timing issues. On the positive side, if 
there's a single WG with two tracks, there would be synergy and 
collaborative review between the subgroups. Yaakov is concerned 
about NTP's future, specifically for TICTOC Use Case 2. Karen 
stated that in a perfect scenario NTP would be the timing protocol 
and all IETF efforts would focus on advancing that protocol; 
however, that is not the current reality in the IETF. No clear 
consensus was reached beyond the fact that the working group 
really needs to complete its current charter items and that there is 
concern in the IETF about the resources associated with two time 
related working groups. 

The meeting was adjourned. 

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

---

From: Danny Mayer <[email-masked]>
Date: Tue, 18 Dec 2007 23:56:31 -0500

Odonoghue, Karen F CIV NSWCDD, W13 wrote:
> Folks,
> 
> Below are draft minutes from our recent meeting. If you have any comments
> 1740 – 1950, Monday, December 3, 2007
> 

I'm not sure that I agree with this. I would prefer that we figure out
*first* what should be done and then write the document. It's too late
if you allow something initially and later want to restrict it. You
won't be able to go back.

> included via reference to ID?  Brian Haberman’s suggestion is

That was one of my recommendations. One of the other ones was to include
an NTP timestamp in the initial DHCP response (BOOTP?) so that a client
without a TOY can get at least an approximately idea of the current time
which would later be adjusted with NTP.

> three years later we’re still trying to get NTPv4 completed. NTPv4

While the code base is changing it's to improve the algorithms and ways
of handling different configurations. It really is not a protocol issue
and should not affect the NTP v4 spec in any way. The reference
implementation is just that, a reference implementation and changes
being made are to support more and varied configurations and
circumstances. Other implementations should feel free to not try to
follow this and the spec should not require it. The NTPv4 draft is about
how to get an implementation to interoperate with other servers,
correctly interpret the other's packets and make calculations to correct
and discipline the system clock. Some implementations will do this
better than others.

> there’s a single WG with two tracks, there would be synergy and
> about NTP’s future, specifically for TICTOC Use Case 2. Karen

Personally, I don't care what the WG is called, though TICTOC is still a
BOF rather than a WG. There are different issues being addressed in the
two groups and if that means two subgroups under an umbrella group,
that's fine. The current TICTOC seems to be concerned about IEEE1588v2
and support for it. I'm sure there's more than that but it didn't come
through very well. From NTP's point of your that's something several
levels below the one that NTP operates on and therefore by it's very
nature will have a more restricted applicability. I suspect that NTP
would probably implement 1588 as a refclock.

Outside of IEEE1588v2 what does TICTOC want to get done? The same
question about NTPv4, autokey and MIB needs to be asked of the NTP WG. I
do know of one authentication proposal that has been raised but it needs
to be drafted.

Danny

---

From: Shane Kerr <[email-masked]>
Date: Wed, 19 Dec 2007 14:02:55 +0100

Danny,

> do know of one authentication proposal that has been raised but it needs

I was at the TICTOC BoF, and some of the ideas were interesting to me (as a
non-time guy):

- Using different paths for time than for other network activity (since we care
  about jitter not delay):

- Recording the delays introduced by routers and switches in the path a packet
  takes from one point in the network to the other to give more accurate time.

I would say that TICTOC did *not* seem to be concerned only with IEEE 1588,
although one message I came away with was that IEEE 1588 comes out of a more
experimental direction than most IEEE standards that the IETF deals with, and so
is very open to working with other groups on making it more useful.

If you didn't see them, slides are available at:

http://www3.ietf.org/proceedings/07dec/slides/tictoc-0/
http://www3.ietf.org/proceedings/07dec/slides/tictoc-1/
http://www3.ietf.org/proceedings/07dec/slides/tictoc-2/
http://www3.ietf.org/proceedings/07dec/slides/tictoc-3/
http://www3.ietf.org/proceedings/07dec/slides/tictoc-4/

My basic sense of the room was that people are interested in doing time-related
work, but don't know where to do that at the IETF, hence TICTOC.

--
Shane

---

From: Danny Mayer <[email-masked]>
Date: Sun, 23 Dec 2007 13:38:50 -0500

> I was at the TICTOC BoF, and some of the ideas were interesting to me (as a

Unfortunately, I couldn't be there but I was listening on the audio
relay. I did have to go to a staff meeting during the latter part of the
meeting and was amazed the the meeting was still going on when I
returned an hour later!

> - Using different paths for time than for other network activity (since we care

Well we do care about delay if it's asymmetric since the calculations
can make no other assumptions that might be valid. Remote servers are
likely to have asymmetric delays since the return packet can get routed
any way. Local on-LAN delays are most likely to be symmetric. The
biggest problem is measuring the asymmetry.

>   takes from one point in the network to the other to give more accurate time.

The problem that I see with this is that it ignores the propogation time
of the medium, be it fiber, copper, wireless or something else. Each of
these medium will have different propogation times. In addition you will
have older routers and switches in the path that won't recognize that
they have to add their own delay and just forward the packet. Consider
the Interplanetory Internet for example. Sending a packet from a
spacecraft orbiting Mars to a station on Earth, for example, has very
long delays AND asymmetry since the  returned packet will be returned
from a different location on Earth than when it arrived AND the position
of the spacecraft will have changed. I realise that this is an extreme
example (well today it is, tomorrow it will be commonplace) but it gives
you an idea of what we have to struggle with.

> If you didn't see them, slides are available at:

I followed them during the meeting so I have seen them.
> work, but don't know where to do that at the IETF, hence TICTOC.

We'd be happy to work with them. I just need to understand their problem
space.

Danny

---

From: Rob Seaman <[email-masked]>
Date: Sun, 23 Dec 2007 13:52:31 -0700

On Dec 23, 2007, at 11:38 AM, Danny Mayer wrote:

> Consider the Interplanetory Internet for example. Sending a packet  
> from a spacecraft orbiting Mars to a station on Earth, for example,  
> has very long delays AND asymmetry since the  returned packet will  
> be returned from a different location on Earth than when it arrived  
> AND the position of the spacecraft will have changed.

This is a different problem regime.  The light time delay is highly  
predictable, whether or not it is asymmetric.  The general issue of  
"world coordinate systems" and space-time coordinates is quite active  
in the astronomical computing community - you can benefit from side  
channel information about the relative positions of the endpoints of  
each link.

> I realise that this is an extreme example (well today it is,  
> tomorrow it will be commonplace) but it gives you an idea of what we  
> have to struggle with.

The Earth-bound challenges are likely to dwarf any spacecraft issues.   
The relative complexity is opposite to what you suggest.  Also, just  
as Jetson transport never took off commercially, so it is unhelpful to  
assume that we'll be nonchalantly zipping around the solar system in  
the coming century.

Rob Seaman
National Optical Astronomy Observatory

---

From: Danny Mayer <[email-masked]>
Date: Sun, 23 Dec 2007 16:29:17 -0500

> channel information about the relative positions of the endpoints of  

Very true. My Master's degree is on General Relativity by the way so I'm
well aware of the issues. I am also interested in the work that NIST is
doing where they are already needing to incorporate general relativistic
principles to measure time and frequency accurately. Yes side channel
information is helpful here though I don't know how accurate the current
technology is. I haven't tried to keep up.

> assume that we'll be nonchalantly zipping around the solar system in  

No, but I expect many more spacecraft out there.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 24 Dec 2007 22:39:02 -0500

> channel information about the relative positions of the endpoints of  

I forgot to comment on this one. The packet follows the geodesic which
is a 4-dimensional path so you cannot just locate the 3-d coordinates of
each endpoint and calculate the distance between them.

Danny

---

From: Rob Seaman <[email-masked]>
Date: Thu, 27 Dec 2007 16:47:10 -0700

On Dec 24, 2007, at 8:39 PM, Danny Mayer wrote:

> I forgot to comment on this one. The packet follows the geodesic  
> which is a 4-dimensional path so you cannot just locate the 3-d  
> coordinates of each endpoint and calculate the distance between them.

Even if the Newtonian approximation doesn't apply, there is a physical  
model that can be run through the Runge-Kutta mill to deliver an  
estimate of the light travel time to whatever precision needed.

More fundamental is that even Einstein had to punt on the central  
conceit of NTP.  It may seem logical that the timestamp "midway"  
between event A and event B is (A+B)/2, but this is the "standard  
synchrony" of relativity - that is, an inductive assumption, not a  
deductive conclusion.

Rob Seaman

---

From: Danny Mayer <[email-masked]>
Date: Fri, 28 Dec 2007 22:22:30 -0500

> estimate of the light travel time to whatever precision needed.

I admit to not having looked at RK for quite a few years!

> synchrony" of relativity - that is, an inductive assumption, not a  

Agreed. I'm not really sure what the midpoint really means in such a
case never mind what the timestamp would be for it. That boggles the mind.

Danny

---

From: "David L. Mills" <[email-masked]>
Date: Sun, 30 Dec 2007 05:18:25 +0000

Danny,

At the risk of being briefly off-topic, a few years ago I and students 
were working the problem that, given the ephemeris of a spacecraft with 
synchronized clock and another spacecraft with given ephemeris but 
unknown clock, how could that clock be synchronized? Our solution was an 
iterated algorithm that first deterimed the lightime relative to an 
assumed unknown clock, then determined the position at that time, 
compared to the calculated lighttime and iterated. Generally, only a few 
iterations were necessary to converge. This did not consider gravity and 
time dilation effects.

Dave