<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Following up from the comment Marc made - if we want to use NDN as the protocol to <em>achieve</em> clock synchronization (i.e. replace NTP’s current UDP transport) then we’d better not build any clock dependencies into the base protocol as mandatory elements. That doesn’t mean we have to eschew all clock synch invariants, only those that would get in the way. For example, it’s probably fine to depend on absolute time for data expiration and any cache control directives, since a clock synchronization protocol would likely be hopelessly broken no matter what if it either used a non-zero lifetime or allowed clock values to fetched from a cache.</p>
<p dir="auto">On 12 Jun 2019, at 6:34, Viktor S. Wold Eide wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Thanks for the follow up and viewpoints.<br>
<br>
As written, the NDN Protocol design principles states universality<br>
(including IoT and other highly constrained environments) and that the<br>
core network protocol operations should not depend on clock<br>
synchronization. Hence, I expected that to be the case.<br>
<br>
During testing I experienced that NLSR did not work as expected<br>
(although I'm not sure to what extent NLSR is considered core<br>
protocol). To me, before starting to look more closely into it, the<br>
system appeared brittle / faulty. I may have overlooked something, but<br>
I did not see any log messages from the system indicating insufficient<br>
clock synchronization or clock skew being outside acceptable<br>
boundaries.<br>
<br>
It appears reasonable, that if some parts of the NDN core systems<br>
assumes clock synchronization to be within some specific boundaries,<br>
it should be explicitly stated as a requirement. Additionally,<br>
protocols / software should then also detect and handle<br>
synchronization problems in a deterministic / predictable way, and not<br>
silently fail or operate in unpredictable ways.<br>
<br>
I wanted to ask here to clarify the NDN clock synchronization<br>
requirements in general. From the design principle and your first<br>
sentence, I would assume that your viewpoint is controversial. I<br>
understand that your viewpoint is to require rather tight clock<br>
synchronization, maybe even sub-second. That is currently contrary to<br>
one of the listed main design principles of NDN.<br>
<br>
To me then, the clock synchronization requirements in NDN appear<br>
unclear / unresolved / in conflict :<br>
<br>
- the design principles state that the core network protocol should<br>
not depend on clock synchronization.<br>
<br>
- some NDN protocol / software (NLSR, other?) implementation appear to<br>
assume and depend on clock synchronization for correct operation.<br>
<br>
<br>
Which other parts of NDN core system depend on clock synchronization?<br>
In case, to what extent?<br>
<br>
If and in case to what extent have the NDN protocols / implementations<br>
moved away from the NDN design principle regarding clock<br>
synchronization?<br>
<br>
Are there any NDN "official" viewpoints on clock synchronization<br>
requirements, which could indicate where this is heading protocol-wise and<br>
implementation-wise in the near future?<br>
<br>
<br>
Best regards<br>
Viktor S. Wold Eide</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">DaveO</p>
</div>
</div>
</body>
</html>