[Ndn-interest] Ndn clock synchronization requirements

[David R. Oran]

Probably not a good idea to weigh in on this, but my views are well 
known and I’ll take the heat for repeating them here.

On 11 Jun 2019, at 10:03, Viktor S. Wold Eide via Ndn-interest wrote:

> Dear list members,
>
> The NDN Protocol design principles state that the core network 
> protocol
> operations should not depend on clock synchronization:
> https://named-data.net/project/ndn-design-principles/
>
> I do look into this from the perspective that hosts should be able to 
> only
> rely on their internal clock, that is, without depending on any kind 
> of
> network time protocol synchronization.
>
This is a very bad tradeoff in my opinion. We are now at the point that 
our civilization will collapse if loosely synchronized absolute time 
stops being available (e.g. GPS). Deciding to not depend on loosely 
synchronized absolute time and using delta time and its vagaries with 
respect to network latency and queueing delays (not to mention storage 
delays) seriously hampers all aspects of a new protocol architecture 
like NDN.

Providing such clocks is becoming cheaper and cheaper, and reasonable 
for all but the lowest-end sensor/IoT devices. This problem may fix 
itself as technology improves, but even if it doesn’t, it’s nearly 
certain that such devices will be only one network hop away from a 
reliable source of absolute time that can be fetched and adjusted 
frequently enough that the bad oscillators in these devices won’t 
drift out enough to matter (for things that don’t need better than 1s 
or even 100ms accuracy).

With a few exceptions, NDN should switch over to absolute rather than 
relative time for data expiration, key lifetimes, and cache control 
directives. (CCNx has already done this). The only reasonable exceptions 
are timers that operate on RTT timescales, like Interest lifetime 
(assuming no long-lived interests, as some NDN things like Kite use) 
where delta time does not pose a problem.

Aside from the direct NDN protocol design benefits, having reasonably 
good absolute time accuracy dramatically simplifies many distributed 
algorithms.

> I have been doing some testing with the Ndn software, including the 
> most
> recent version of NLSR. From what I see, NLSR requires clocks on 
> different
> hosts to be fairly well synchronized. The clock synchronization 
> requirement
> is stated in the "Lessons from development and deployment" section in 
> [1]
> from 2016 : "... This means that the network has to be roughly time
> synchronized for the protocol to work. ..."
>
> I could not see a clock synchronization requirement listed elsewhere, 
> but I
> might have overlooked something.
>
> I see that the testbed page notes the following :
> Clock Skew Status: (As compared to UCLA Node's time: Green: < 5 secs 
> off;
> Yellow: 5 < > 30 secs; Red: > 30 seconds off). This might be 
> interpreted as
> the host clocks should be synchronized to, preferable within 5 
> seconds, and
> at least within 30 seconds.
>
>> From what I understand clock synchronization is currently required 
>> for the
> following:
> - certificates to be within valid range
> - NLSR LSA timeout handling
>
> This leads to the following questions:
>
> Is there anything else or in NDN core network protocol operations that
> require clock synchronization? In case, to what extent?
>
> I guess clock synchronization can be made very relaxed for certificate
> validation? For example on the order of many hours clock skew.
>
> Has anyone looked into ways to change / modify the NLSR protocol / 
> software
> in such a way that it is not dependent on clock synchronization? Or at
> least not to this level of synchronization.
>
I advocate doing exactly the opposite.

>
> [1]  NDN, Technical Report NDN-0037, 2016.
> http://named-data.net/techreports.html
> Revision 1: January 26, 2016.
> https://named-data.net/publications/techreports/ndn-0037-1-nlsr/
>
>
> Best regards


> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

DaveO