Subject: [6tisch] review of draft-vilajosana-6tisch-globaltime-00

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Mon, 9 Apr 2018 11:26:21 +0200

Hello Xavi and co-authors,

Many thanks for such draft. It is indeed something that we were missing here.
I found some time to go through, and below you will find my comments/questions:

—— 
“It is well-known that the smaller the guard time, the smaller the tolerated drift between two nodes, and hence the more precise their synchronization.”

GP: the last part of this sentence (“and hence the more precise their synchronization.") is not always true, isn’t it?
It is true when you are having very frequent Keep Alive and EB transmissions, otherwise, the smaller the guard time, the higher the probability of desynchronization between the two devices.

—— 
“Optionally, periodic refresh messages can be issued by the 6TiSCH node to the node that acts as global time source, through a provided CoAP URI exposing the time service.”

GP: I am wondering whether such periodic refresh message should be Optional or Default to cope with potential drifts.

—— 
"An optional gt_lease value in days indicating the mandatory refresh period MAY be present."

GP: again, considering the potential drifts, do you think the refresh period should be Optional and not included by Default?

—— 
“If this value is 0, a node does not refresh the global time information.”

GP: any use-case where a node does not need to refresh?

——
Some minor typos: 

"This time is relative to the moment the network started or reset and hence cannot be used to compare tagged events from different networks.”
GP: "and hence" I would assume, it would need a comma : —> "and, hence,"

* “The global time reference is a a mapping between the ASN of the network and the global time at the moment of processing the Join Response.”
GP: remove the extra “a”.

* e.g., or e.g.
GP: you may want to uniformalize it.

Best,
Georgios

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Fri, 20 Apr 2018 15:29:43 +0200

Dear Georgios,

thanks so much for your detailed review. Let me answer inline.

The fixes will appear in a next version of the draft.

kind regards
Xavi

2018-04-09 11:26 GMT+02:00 Georgios Z. Papadopoulos <
[email-masked]>:

> “It is well-known that the smaller the guard time, the smaller the
> tolerated drift between two nodes, and hence the more precise their
> synchronization.”
>
> GP: the last part of this sentence (“and hence the more precise their
> synchronization.") is not always true, isn’t it?
> It is true when you are having very frequent Keep Alive and EB
> transmissions, otherwise, the smaller the guard time, the higher the
> probability of desynchronization between the two devices.
>

XV: I would say now (fixing the traffic)

  “It is well-known that, for a given network traffic, the smaller the
guard time, the smaller the tolerated drift between two nodes, and hence
the more precise their synchronization.”

> ——
> “Optionally, periodic refresh messages can be issued by the 6TiSCH node to
> the node that acts as global time source, through a provided CoAP URI
> exposing the time service.”
>
> GP: I am wondering whether such periodic refresh message should be
> Optional or Default to cope with potential drifts.
>
>
XV: What if the network has an inherent mechanism that compensates the
drift and hence nodes are always perfectly synchronized?  I agree that this
may be an edge case and the normal case is that nodes poll periodically the
time source. Does it hurt however to have that mechanism as optional?

> GP: again, considering the potential drifts, do you think the refresh
> period should be Optional and not included by Default?
>
> XV: see above.

> XV: see above.

>
> ——
> Some minor typos:
>
> "This time is relative to the moment the network started or reset and
> hence cannot be used to compare tagged events from different networks.”

XV: fixed that.Thx!

>
> * “The global time reference is *a a* mapping between the ASN of the
> network and the global time at the moment of processing the Join Response.”
> XV: fixed that.Thx!

> * e.g., or e.g.
> GP: you may want to uniformalize it
>
> XV: fixed that.Thx!

> Best,
> Georgios
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain