Subject: Re: [ntpwg] KoD 'backoff' BCP/direction

From: Danny Mayer <[email-masked]>
Date: Sun, 01 Jun 2008 09:32:21 -0400

Dave,

No, they are not yours, they are mine. This is deliberate since your 
reference implementation is just that. There are lots of other 
implementations with NTP and especially SNTP and they need to know what 
they need to do when they receive such a KOD packet.

Danny

David L. Mills wrote:
> Danny,
> 
> These are not my words; I wish they would go away in a formal 
> specification document. My recommendation, and I spent a good deal of 
> time on it, is the headway scheme described in the current documentation 
> and now implemented. This may not be the only scheme, but should serve 
> as a model for future adaptations.
> 
> Dave
> 
> Danny Mayer wrote:
> 
>> Harlan Stenn wrote:
>>
>>> The draft says:
>>>
>>> a. For kiss codes: DENY, RSTR the client MUST demobilize any
>>> associations to that server and stop sending packets to that
>>> server;
>>>
>>> b. For kiss code: RATE the client MUST immediately reduce its
>>> polling interval to that server and continue to reduce it each
>>> time it receives a RATE kiss code.
>>>
>>> >From my POV this is almost helpful.
>>>
>>> For case (a), for what duration SHOULD the client demobilize and stop
>>> sending packets to that server?
>>>
>> Indefinitely. It should never try and contact that server again.
>>
>>> For case (b), are there any recommendations on how much the client
>>> SHOULD reduce the rate at which it is polling the server?
>>>
>> No. It was deliberately left vague. It's hard to decide that question. I
>> would recommend backing off by doubling the interval between polls every
>> time one of these packets is received.
>>
>>> In case (b), do we mean 'polling rate' (or frequency) instead of
>>> 'polling interval'?
>>>
>> Yes, that's an error on my part. Thanks for catching it. It should be
>> reduced frequency.
>>
>>> Is there an easy way the server could 'offer a suggestion' in either of
>>> these cases? What are the costs/benefits to having the server offer
>>> ideas on these rate limits instead of relying solely on the client?
>>
>> The server can never really make recommendations. That's up to the
>> implementation, dependent on requirements. Saying "back-off" should be
>> enough for the client to take the appropriate action.
>>
>> Danny
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Rob Seaman <[email-masked]>
Date: Sun, 1 Jun 2008 12:35:12 -0700

TS Glassey wrote:

> the NTP we are working on is a technical curiosity since without  
> those corporate client's and their users, most of us have nothing to  
> do.

A pretty successful technical curiosity, serving a wide range of  
purposes here.  Corporate mileage may vary, but again - what keeps the  
Fortune 500 from buying their own clocks?  Oh, that's right - nothing:

	http://www.romainjerome.com/en/les-inatendus/day-and-night-en.aspx

Tag line:  "An exceptional timepiece that does not indicate the time!"

Not only is better the enemy of good enough - sometimes it isn't even  
better :-)

Some people have nothing to do, indeed.

Brian Utterback wrote:

> Auditor's don't pay. Auditor's never pay.

Yeah - I thought somebody would point that out.  But "physicist" was  
an even poorer fit to the true stakeholders.  In any event, if the  
government or corporate world need a timekeeping system with certain  
characteristics, they have copious resources to bring this into  
being.  That they may not recognize their needs in this area is not  
the fault of the kind and clever folks who have toiled thanklessly on  
the excellent NTP.

> Auditor's issue requirements and other people pay to meet them.

Requirements are not issued, they are implicit in the problem being  
solved and must be discovered.

M. Warner Losh wrote:

> A similar situation with leap seconds: They have been promulgated  
> and everybody must cope.

Well - no.

The world turns.  The moon steals its angular momentum.  Some  
mechanism is needed to accommodate.  It may not be leap seconds, but  
the requirement exists whether or not crabby astronomers point it out.

> it is safe to say that NTP implements them because they are a  
> requirement of UTC time.

Again - no.  NTP implements leap seconds because they are a feature of  
UTC.  UTC itself has been selected to satisfy numerous requirements.   
We're constantly confusing the activities of problem definition,  
requirements discovery, and the specification of a conforming solution.

> Wouldn't the need to have a traceable UTC merit consideration?  Or  
> at least an explicit mention as beyond the scope?

These traceability requirements have yet to be discovered.  There is  
simply a hazy assertion that they exist.  I don't disagree, since they  
aren't well enough elaborated to construct an opinion - even of  
whether they are beyond the scope of the system in question.  What  
that says to me is that the current work before the group should be  
wrapped up with a pretty bow before any other action is taken.

Voltaire also said, "Perfection is attained by slow degrees; it  
requires the hand of time."

Rob Seaman
NOAO

---

From: Rob Seaman <[email-masked]>
Date: Sun, 1 Jun 2008 09:35:43 -0700

Oh - why not?

On Jun 1, 2008, at 7:50 AM, TS Glassey wrote:

> I think the biggest problem we are running into is that NTP is a  
> utility that has become critical for proper operations of systems  
> meaning that its now more important to Auditors than to the  
> Physicists who designed the idea of NTP.

And are physicists or auditors more important to the rest of us?  :-)

Less snarkily, requirements may derive from either economic or  
scientific use cases, but system design is about engineering.

> The problem is that Auditor's need something much different than  
> what you folks are arguing about

So NTP is something that doesn't address the needs of your community.   
Which begs the question:  Why don't the auditors pay somebody to build  
a system that does?  They certainly have more money than the  
physicists.  Kind of embarrassing really if the auditors are failing  
to account for the proper value of timekeeping.

> But before anyone here starts making proclamations as to what NTP  
> needs you need to establish the viewpoint perspective of the person  
> uttering that commentary since if its not from an Auditor - it  
> should ONLY be about the precision of the time data moved about a  
> network.

Sounds like a proclamation to me :-)

> I would use XML messaging too to insure that the messages can be  
> properly managed as well.

Snort!

Rob Seaman
National Optical Astronomy Observatory

---

From: "M. Warner Losh" <[email-masked]>
Date: Sun, 01 Jun 2008 12:43:05 -0600 (MDT)

In message: <[email-masked]>
            Brian Utterback <[email-masked]> writes:
: Rob Seaman wrote:
: > So NTP is something that doesn't address the needs of your community.
: > Which begs the question:  Why don't the auditors pay somebody to build  
: > a system that does?  They certainly have more money than the  
: > physicists.  Kind of embarrassing really if the auditors are failing  
: > to account for the proper value of timekeeping.
: >   
: 
: Auditor's don't pay. Auditor's never pay. Auditor's issue requirements 
: and other people pay to meet them.

Yes.  A similar situation with leap seconds: They have been
promulgated and everybody must cope.  Some people like coping because
it saves them money, others don't because it costs them money.
Regardless of which side of the fence you are on with this issue, it
is safe to say that NTP implements them because they are a requirement
of UTC time.

Wouldn't the need to have a traceable UTC merit consideration?  Or at
least an explicit mention as beyond the scope?

Warner

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 1 Jun 2008 10:35:12 -0700

Brian (please don't take these acerbic words personally - there are many 
wizards here...)

----- Original Message ----- 
From: "Brian Haberman" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: <[email-masked]>; "David L. Mills" <[email-masked]>; <[email-masked]>
Sent: Sunday, June 01, 2008 10:10 AM
Subject: Re: [ntpwg] KoD 'backoff' BCP/direction

> Todd,
>      I agree that there are people in the world (e.g., auditors) that need 
> a different mechanism than NTPv4.  However, we are not chartered to 
> develop this *new* time protocol.  We are chartered to publish the NTPv4 
> specification.

Then the Charter is broken - since NTP4 is with these extensuions trying to 
be all things to all people, and it cannot be by NTP's very design.

> I would highly encourage *anyone* who sees new requirements for time 
> synchronization to get fully engaged in the TICTOC effort and help 
> structure their approach to address these new requirements and/or usage 
> models.

TICTOC (the IETF's new Precision Time WG is even more clueless IMHO).

>
> Regards,
> Brian
>
> TS Glassey wrote:
>> Folks
>> I think the biggest problem we are running into is that NTP is a utility
>> that has become critical for proper operations of systems meaning that 
>> its
>> now more important to Auditors than to the Physicists who designed the 
>> idea
>> of NTP.
>>
>> The problem is that Auditor's need something much different than what you
>> folks are arguing about and its actually kinda funny watching the blind 
>> lead
>> the blind here. But before anyone here starts making proclamations as to
>> what NTP needs you need to establish the viewpoint perspective of the 
>> person
>> uttering that commentary since if its not from an Auditor - it should 
>> ONLY
>> be about the precision of the time data moved about a network.
>>
>> Personally the Status Process and all of the communications between the 
>> Server and the Client querying it should be through a Tunnled TCP 
>> connection and not NTP's UDP periodic packaet stream. I would use XML 
>> messaging too to insure that the messages can be properly managed as 
>> well.
>>
>> And YES David - I think Danny is right here, but even his work should be 
>> optional in the implementaiton.  By the way - SNTP needs AutoKEY for 
>> local delivery only. The use of SNTP needs to be limited to local 
>> networks only IMHO.
>>
>>
>> Todd Glassey
>>
>> ----- Original Message ----- 
>> From: "Danny Mayer" <[email-masked]>
>> To: "David L. Mills" <[email-masked]>
>> Cc: <[email-masked]>
>> Sent: Sunday, June 01, 2008 6:32 AM
>> Subject: Re: [ntpwg] KoD 'backoff' BCP/direction
>>
>>
>>> Dave,
>>>

---

From: Brian Utterback <[email-masked]>
Date: Sun, 01 Jun 2008 14:30:45 -0400

> to account for the proper value of timekeeping.

Auditor's don't pay. Auditor's never pay. Auditor's issue requirements 
and other people pay to meet them.

---

From: Brian Haberman <[email-masked]>
Date: Sun, 01 Jun 2008 13:10:07 -0400

Todd,
      I agree that there are people in the world (e.g., auditors) that 
need a different mechanism than NTPv4.  However, we are not chartered to 
develop this *new* time protocol.  We are chartered to publish the NTPv4 
specification.  I would highly encourage *anyone* who sees new 
requirements for time synchronization to get fully engaged in the TICTOC 
effort and help structure their approach to address these new 
requirements and/or usage models.

Regards,
Brian

TS Glassey wrote:
> that has become critical for proper operations of systems meaning that its
> now more important to Auditors than to the Physicists who designed the idea
> of NTP.
> 
> folks are arguing about and its actually kinda funny watching the blind lead
> what NTP needs you need to establish the viewpoint perspective of the person
> uttering that commentary since if its not from an Auditor - it should ONLY
> Server and the Client querying it should be through a Tunnled TCP connection 
> and not NTP's UDP periodic packaet stream. I would use XML messaging too to 
> insure that the messages can be properly managed as well.
> 
> optional in the implementaiton.  By the way - SNTP needs AutoKEY for local 
> delivery only. The use of SNTP needs to be limited to local networks only 
> IMHO.
> 
> 
> Todd Glassey
>

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 1 Jun 2008 10:46:46 -0700

----- Original Message ----- 
From: "Rob Seaman" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, June 01, 2008 9:35 AM
Subject: Re: [ntpwg] KoD 'backoff' BCP/direction

> And are physicists or auditors more important to the rest of us?  :-)

Apparently not Rob meaning that the NTP we are working on is a technical 
curiosity since without those corporate client's and their users, most of us 
have nothing to do.

> to account for the proper value of timekeeping.

The reasons for that have more to do with arrogant Systems Administrator's 
who put the white coat on and screamed "Believe me because I am a scientist 
and I know right" - what a crock of merde...

> Sounds like a proclamation to me :-)

It is. And its based in this groups blanket and repeated refusal to build an 
'approved BCP for the use of NTP'.

>> properly managed as well.

Yeah I know - XML is ... well painful and a waste for many processes but 
this is about producing both human and machine readable records of events 
which we are trying to attest a formal evidence of a time-setting or 
time-assay event.

---

From: "TS Glassey" <[email-masked]>
Date: Sun, 1 Jun 2008 07:50:36 -0700

Folks

Todd Glassey

---

From: Danny Mayer <[email-masked]>
Date: Sun, 01 Jun 2008 18:53:56 -0400

TS Glassey wrote:

> messaging too to insure that the messages can be properly managed as well.

This won't happen, EVER. It seems you don't understand the problem 
space, never mind the solutions to it. Go read the project documentation 
to find out why.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sun, 01 Jun 2008 18:55:05 -0400

> And are physicists or auditors more important to the rest of us?  :-)

Well, people like you working in astronomy need the accuracy otherwise 
your telescopes will miss their targets. It's not clear that the 
auditors will have a clue in the first place.

>> what you folks are arguing about

They may know what they need but they have no clue about how to get it.
> to account for the proper value of timekeeping.

Almost no auditor needs the kind of accurate timekeeping that NTP 
provides. While it's true that they make lots of money, they do it on 
the dime of the people that they are auditing.

>> properly managed as well.

XML has nothing to do with managing messages.

Danny

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 2 Jun 2008 06:44:31 -0700

Danny, I haven't laughed so hard in months. Thanks! Ahahahahahaha hahahaha -

As it happens I think the tone of your response says everything that the
people writing checks for those participating here need to see.

Todd Glassey

---

From: Rob Seaman <[email-masked]>
Date: Mon, 2 Jun 2008 07:43:58 -0700

Let's jump back to the real issue.

> TICTOC (the IETF's new Precision Time WG is even more clueless IMHO).

Until the activities of NTPWG are finished, there is no basis to  
evaluate the performance of its successor.  You could also pursue your  
goals outside the IETF bailiwick.

The best and quickest way to move things forward is to wrap up the  
current business before this WG, not to attempt to introduce new  
requirements or features.

Rob Seaman
NOAO

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 2 Jun 2008 07:59:38 -0700

Rob -
----- Original Message ----- 
From: "Rob Seaman" <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 02, 2008 7:43 AM
Subject: Re: [ntpwg] KoD 'backoff' BCP/direction

> evaluate the performance of its successor.

I dont want or need to evaluate the NTP Successor - its hear already... 
NTPDate is it for end-users. The only people that need NTP Daemon's are 
people who need to have their remote value checked by some other station and 
we have done that with embedded peer type systems already.

> You could also pursue your

We are. But this group is as well which is where all of this convo on the 
KoD came from.

Cracks me up - you know from a legal standpoint there is no IP transfer 
between the participants of HACKERS and the participants of NTPWG, except 
that NTPWG appears to magically own the Engineering Consulting 
Workproduct/output of HACKERS so it can assign it to the IETF.

What a mess...

> requirements or features.

No Rob - the best way to move forward is to use a uniform set of development 
assignments (IP Rights) and their owners across the whole process. The 
NTP.ISC.ORG operations are not doing that now but can easily be setup to do 
so.

And BTW if you want to see if your organization supports that or your 
assertions or mine here, lets get your general counsel involved... As I 
recall Carrie-Nunes was the Assistant/Acting GC for you folks, is that still 
true?

---

From: Rob Seaman <[email-masked]>
Date: Mon, 2 Jun 2008 09:19:09 -0700

Hi Todd,

This has clearly passed the point of diminishing returns.

> I dont want or need to evaluate the NTP Successor

Ok.  Then my advice is to let this NTP update cycle finish and try to  
influence the next.  You don't appear to have any hope of gaining  
traction on these issues so late in the game.

> the best way to move forward is to use a uniform set of development  
> assignments (IP Rights) and their owners across the whole process.

You are discussing questions of design.  I am discussing questions of  
process.  Any development cycle starts with design issues and ends  
with implementation issues.  It is simply too late to influence the  
current cycle (other than to slow it down).

> The NTP.ISC.ORG operations are not doing that now but can easily be  
> setup to do so.

Write a white paper now, to influence decisions later.

> And BTW if you want to see if your organization supports that or  
> your assertions or mine here, lets get your general counsel  
> involved...

I don't recall making any assertions.  It would be pointless to  
construct an opinion on the skimpy basis available at the moment.   
 From your association with Certichron it is clear that you have a  
horse in this race.  I'm personally only interesting in seeing the  
race actually occur.

(BTW, I might find some other analogy than "trust-anchor".  It really  
conjures visions of walking the plank and having ones cargo of trust  
carried downward into the inky blackness.  An anchor is also only a  
temporary mooring, sometimes slips on the sea floor, and occasionally  
has to be cut loose and left behind.  A single anchor leaves the  
vessel free to swing willy-nilly in a large arc with the wind and  
water.)

> As I recall Carrie-Nunes was the Assistant/Acting GC for you folks,

Not sure who this is or who "you folks" refers to.

In any event, legal and economic use cases are indeed significant.   
I've spent eight years arguing this regarding leap seconds.  However,  
you haven't connected the dots to show that NTP is unresponsive to  
these.  In fact, your participation here suggests that no other  
technology is more mature for your purposes.  That being the case, it  
is to your own advantage to move the NTP standards process forward to  
provide yourself the opportunity of hopping aboard the next time the  
carousel goes by.

Rob

---

From: "TS Glassey" <[email-masked]>
Date: Mon, 2 Jun 2008 09:54:18 -0700

Rob - PLEASE DONT TAKE my words personally - the are aimed at creating a 
strong and complete Standards Development Environment for NTP and to 
document and model its use in today's key use markets. :-)

I will also make this my last response to this on the open list. But I 
suggest you look at the retort's herein.

Todd

----- Original Message ----- 
From: "Rob Seaman" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 02, 2008 9:19 AM
Subject: Re: [ntpwg] KoD 'backoff' BCP/direction

> This has clearly passed the point of diminishing returns.

Why - because I suggested we get input from people you work for as to what 
they want here? :-)

Please dont take this personally - I am trying to figure out whether this is 
in fact an International Standards process or just a bunch of guys and gals 
that have an amatuer interest in timekeeping. It clearly makes a difference.

> traction on these issues so late in the game.

The problem is that others have financial investment's in the time-spent 
here and that creates an issue.

> process.

I disagree. But its more an issue of the style - for instance - the code 
changes which are captured in the NTPWG's Document Effort are what we are 
talking about. So how are the IP rights to that codified in a manner which 
can then be assigned to the IETF through the NTPWG's operations ??? See my 
point?

> Any development cycle starts with design issues and ends

My comments above clearly address this as well.

> construct an opinion on the skimpy basis available at the moment.

So then lets ask ALL of our master's what they formally want from NTP and 
its implementation... A simple Survety would do this and add a huge amount 
of credibility to the process - (Look you may not like my attitude on this 
stuff but these ideas are priceless).

> horse in this race.  I'm personally only interesting in seeing the

Cool - I think that is a good goal. One I support.

> carried downward into the inky blackness.

Did you watch the Black Pearl last night?

> An anchor is also only a
> has to be cut loose and left behind.

Trust Assertions are temporary in form. They exist as long as the anchor is 
real and properly rooted in its trust hierarchy.

> A single anchor leaves the

Agreed which is why AutoKEY by itself isnt enough.

> Not sure who this is or who "you folks" refers to.

NOAO.

BTW Did you know my academic minor is Astronomy? I also used to work in 
sub-picosecond physics at SLAC and another 'place' ... Bubble Chamber type 
stuff, so timing is something near and dear to my heart.

> In any event, legal and economic use cases are indeed significant.

Thanks for acknowleding that - can you perhaps also answer why they are 
ignored by this WG in its mad dash to publish?

> I've spent eight years arguing this regarding leap seconds.

Ahh - yes the Leap Second Bingo Game - I wrote a white paper for the 
Securities Industry on this a couple of years ago. A number of larger 
Securities Traders have taken up a two layer timing model to address this, 
its a solution I am very proud of as is my replacement for ACTS solution.

> However,
> these.

Leap Seconds are only relevent to logging operations which need to properly 
codify a process to reintegrate those offsets into them to make the logs 
'propah'. In fact since UTC is calculated and proclaied from BIPM some 30 
days after that point in time this commentary of mine is dead-on here.

> In fact, your participation here suggests that no other
> technology is more mature for your purposes.

true.

> That being the case, it

Not if that means 'breaking it' in the interim. Its better not to have to 
say "I am sorry" and fix something that was done just to get someone elses 
efforts into print. Its better to stop those from being printed and fix the 
problems. The issue here is that some of this group has a vested interest in 
publishing those document's whether they work or not. That is a conflict of 
interest since who is being benefited is the operator of the carousel and a 
very few riders who live under the publish or perish idiom IMHO.

Todd

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 03 Jun 2008 02:08:08 +0000

Danny,

I spent a good deal of time on KoD/backoff schemes in the recent 
version. There is in fact an opportunity to use the received ppoll 
variable under certain circumstances to clamp the transmit poll 
interval, but it is part of the headway scheme and quite intricate. I 
suspect few people will figure out how it works and probably nobody else 
will implement it. I advise leaving the text as is. Leaving some things 
for future refinement is in the best spirit of Internet technology.

Dave

Danny Mayer wrote:

> Brian Haberman wrote:
>> That is my understanding as well.
>>
>>> No. It was deliberately left vague. It's hard to decide that question.
>>> I would recommend backing off by doubling the interval between polls
>>> every time one of these packets is received.
>>>
>> Exponential backoff works well.
>>
>> Why can't the server make a recommendation? In the multicast group
>> management protocols a Query message specifies a delay value that
>> controls the burstiness of the responses sent back. The poll field
>> could be used in the same manner.
>>
>
> It could, but only if it can decide such a value. I'm not clear how it
> could make such a decision since each server will have different
> characteristics. I don't think we can make the poll field contain any
> particular value but I'm open to suggestions on how to implement this.
>
> Danny
>

---

From: Danny Mayer <[email-masked]>
Date: Wed, 04 Jun 2008 22:30:30 -0400

Dave,

That's my opinion too.

Danny

---

From: "TSG" <[email-masked]>
Date: Mon, 9 Jun 2008 16:47:06 -0700

Folks
----- Original Message ----- 
From: "M. Warner Losh" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, June 01, 2008 11:43 AM
Subject: Re: [ntpwg] KoD 'backoff' BCP/direction

> : and other people pay to meet them.

People pay auditor's for all kinds of things. The latest is for designing 
systems and workflow processes which speak for themselves. The real issue is 
that people generally speaking are not trustworthy - statistically 
everything is fine until you need to rely on their testimony and then 
everything changes.

But that wasn't the point - the real issue here is that IT Engineers should 
not be designing trust processes for commercial users without their 
involvement or their specifying what they need. Something this WG has never 
taken a survey in...

Todd