Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13

[Magnus Westerlund <[e-mail]>]

Hi,

I also had some private discussion with Scott Burleigh on this matter
of the clock. What we concluded is that the current clock using Unix
Epoch time adjusted to start 2000 appears fine for the current usages
in DTN. The only implication is that during a positive (added) leap
second, both the leap second and the second before will have the same
seconds since value. Nothing BP can't handle. And during negative leap
seconds the clock will simply skip over that last second of that day.
Neither appear to have any real impact on the protocol. 

However, how leap seconds are handled need to be documented and a
normative reference to the clock needs to be provided. 

Regarding Ran's comments below and my comment regarding 64-bit unsigned
integers. You simply need to document what is expected to happen here.
If you continue to use the seconds since year 2000 started then I
really think you should allow 64-bit precision. The reason is that any
system using this system still will have to know the NTP era, i.e. how
many wraps the NTP 32-bits seconds have done to correctly populate BPs
time field. Note that BP time has one wrap around day for a 32-bit
counter, NTP has another and Unix Epoch time a third. Thus tracking the
wraps becomes necessary, or at least knowing that one have a clock
system that will know the year correctly to derive the era. 

So my comment here was really one part failure to understand your
requirements and one part this is insufficiently specified. 
I now have a better understanding of your considerations, so fixing the
insufficiently specified is likely all that is needed. 

Cheers

Magnus Westerlund


On Sun, 2019-07-07 at 15:27 -0400, R. Atkinson wrote:
> > On Jul 5, 2019, at 10:06, Magnus Westerlund <
> > [e-mail]> wrote:
> >  
> > 2.       Section 4.1.6:
> >  
> > I think the format and definition of this field are insufficient.
> > It is lacking a reference or a normative description of what "Unix
> > Epoch Time" in an unsigned int format actually is. Is the intention
> > here to simply measure the number of seconds since the start of
> > year 2000? Which Unix epoch time is not due to leap seconds. And I
> > become uncertain as UTC time scale is something else than Unix
> > Epoch time at least when it comes to leap seconds handling. Due to
> > that Unix Time have discontinuities in the time scale at leap
> > seconds I would recommend strongly against using it. Select UTC or
> > TAI depending on where you want the leap second handling pain to
> > exist. 
> >  
> > Also, you specified only CBOR unsinged integer which is a
> > representation that can use 64-bit and thus not have the issues
> > with 32-bit signed integer seconds epochs that regular unix time
> > has, but that should probably be made explicit that it is expected
> > to handle that. Even if the first wrap of this unsigned 32-bit
> > format will not occur until 2136. 
> >  
> > And please provide necessary normative references, not informative
> > ones. 
> 
> Nota Bene:  I understand that DTN is not mandating the use of any
> particular time synchronisation protocol by a particular DTN
> implementation.  I agree that such is a system time implementation
> decision is outside the DTN protocol scope.
> 
> That said, in the context of widely deployed IETF standards for time
> synchronisation, I wonder whether the right answer really might be to
> specify that this DTN protocol field contains “Time as defined by the
> IETF Network Time Protocol (NTP)”.  NTP is derived from UTC, but its
> epoch is not “seconds since start of year 2000”.  Note also that NTP
> ought not crash in 2036 (which is a common misconception).  Further,
> while Unix systems often use NTP, NTP time is not necessarily
> precisely the same as "Unix time".
> 
> Quoting from Dave Mills (who invented NTP):
> 
> "However, the NTP protocol will synchronise correctly, regardless of
> era, as long as the system clock is set initially within 68 years of
> the correct time.”
> 
> URL for above quote:  "
> https://www.eecis.udel.edu/~mills/ntp/html/warp.html"
> 
> For more about NTP time eras, please see the article by Dave Mills
> which is online here:
>       "https://www.eecis.udel.edu/~mills/y2k.html”.
> 
> The main alternative standards-based  implementation/deployment
> alternative to NTP might be to use time as defined by Precision Time
> Protocol (PTP), which is derived from TAI.  
> 
> A 3rd possibility is to pick something consistent with CCSDS’
> Proximity-1 protocol.  Mills discusses Proximity-1 here:
> "https://www.eecis.udel.edu/~mills/proximity.html"
> 
> In the context of Delay-Tolerant Networking, the clock precision of
> PTP likely is significant overkill, while the lower precision of NTP
> might be more reasonable.  Further, in the context of Delay-Tolerant
> Networking, consistent definition of time matters but the presence of
> leap seconds does not create issues (after all, DTN is supposed to be
> delay-tolerant).
> 
> Maybe just go with NTP time and normatively reference the NTP RFC,
> possibly also with informational references to some of Dave Mills
> documents ?
> 
> What do others think ?
> 
> Yours,
> 
> Ran
> 
> 
> 
> 
> 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------