Xavi,
Great. Can I ask you to focus your IETF 101 on discussing these different
points with the WG?
Thomas

On Wed, Mar 7, 2018 at 5:24 AM, Xavi Vilajosana Guillen <xvilajos...@uoc.edu
> wrote:

> Dear Thomas,
>
> thanks so much for your quick action. See inline our responses. We need
> further discussion at the WG meeting.
>
> ---
>
> issue: confused about time source
> severity: low
>
> The "Global Time Source" section starts with a paragraph which suggests a
> particular node in the network has a global time knownledge.
> Yet, the paragraph after, is seems as if only the JRC can play that role.
>
> XV: the JRC is the initial source of time. and from it another URI can be
> announced for future resynch.
>
> That is entirely OK, but I would just merge those paragraphs and say that
> the JRC has some global time knowledge.
> XV: the intro states that the JRC has the notion of global time and how it
> achieves it is out of the scope of the spec.
> Anyways we will review the text so it is absolutely clear.
>
> ---
>
> issue: synchronization between JRC and network
> severity: high
>
> When the JRC is co-located with the DAGroot, it's "easy" for it to konw
> both the network and global time with nanosecond accuracy.
> But the JRC can be a logical entity locate far from the 6TiSCH network.
> Something in the text needs to state that, and probably say that how the
> JRC sync to the 6TiSCHnetwork is out of scope.
>
> XV: Section 2 states:
> The Join Registrar/Coordinator (JRC) acts as the
>    global time information source for a node when it joins.  How the JRC
>    obtains such global time information is out of scope of this
>    specification.
>
> But I see your point, you want as well to mention that the JRC needs to
> know the ASN and hence it needs to synch to it. We add this sentence as
> well.
>
>
>
> ---
>
> issue: PTP?
> severity: low
>
> Fig. 1 contains "PTP", which isn't reference anywhere in the text AFAICT.
>
> PTP is IEEE1588 for example as mentioned before the figure 1.
>
> ---
>
> issue: byte ordering
> severity: low
>
> Section "Global Time Extension to the Join Response" defines the fact that
> "The 5-byte ASN is carried in network byte order".
> But isn't byte ordering something that is already specified by CBOR?
>
> XV: Yes it is. Should we remove that then?
>
> ---
>
> issue: reference of time mapping
> severity: medium
>
> The specification basically defines a format to say "at ASN X, global time
> is Y".
> In theory, what ASN is used is irrelevant, so I wuoldn't mandate for that
> to be "at which the CoAP Response (e.g, Join Response) is processed".
> You could also simply specify what time it was at ASN 0.
>
> XV: Yes. We consider that idea. This saves 5B. Could the timeslot length
> be changed during network lifetime? if so we need then to keep track of it.
>
> ---
>
> issue: confusion about 3 timestamps
> severity: medium
>
> The format defined in "Global Time Extension to the Join Response"
> contains 3 timestamps: ASN, timestamp in seconds, timestamp in ps.
> I don't understand the description of the latter two. Why not simply "at
> the beginning of that ASN, this is the epoch (possibly split in s and ps)"
>
> XV: this is the NTP format. The seconds timestamp expresses seconds since
> 1st of Jan 1900. The fraction timestamp expresses hundreds of pico-seconds
> for the last second.
> ASN is the reference. It can be elided if we relate it to a well known
> point in time (e.g, ASN 0)
> We need an era counter as well. As per NTP. Since the seconds field wraps
> every 136 years.
>
> ---
>
> issue: freshness of time?
> severity: medium
>
> I don't understand the logic of adding a "the number of days of freshness
> of the assigned global time information".
> Time is the one thing that advanced at 60min per hour, no matter what :-)
> What's the idea behind this?
> The term "freshness" for sure doesn't seem the right one.
>
> XV: this is the lease time. A global time source node can specify for how
> long the time it has leased to the node is considered to be fresh.
> this is to enforce a resynh if needed. For example to make the node
> resynch and discover if a leap_second is coming.
>
> ---
>
> issue: default freshness value
> severity: low
>
> after the following sentence:
> Optionally, an unsigned word lease value indicating the number of days of
> freshness of the assigned global time information.
> you should specify that no value means infinite freshness
>
>
> XV: thanks. we do that.
> ---
>
> issue: what about drift?
> severity: high
>
> the specification is pretty obsessed about leap seconds, a cool thing for
> sure, but not the most important problem.
> IMO, the most important problem is that the root of the TSCH network
> drifts relative to UTC.
> You have 2 options:
>     - you say the root is always sync'ed, i.e. 0 drift. That's hard.
>     - you provide a mechanism which accounts for drift in your format
>     - you leave everything as-is, but force your nodes to refresh their
> time periodically
>
> To be discussed.
> XV: We agree. That is the role of the lease. A node can poll periodically
> the time service to keep clock updated. We would like to discuss further
> before adding content to the spec.
> ---
>
> issue: unit and width confusion for leap second handling
> severity: low
>
> A 16-bit unsigned integer containing an offset in **days** to the
> beginning of the day (0 h UTC) when the next leap second must be applied.
> I assume **days** should be seconds?
>
> If that is the case, there are 86400 seconds in a day, a 16-bit number
> will not be enough.
>
> Are leap seconds always applied at exact second boundaries?
>
> XV: A leap second is announced at most 6 month in advance to when it will
> happen. The correction to be applied is usually to add or remove 1 second at
> the end of the day when the leap second needs to be applied. This is the
> same idea as NTP uses. When a node synchronizes to the
> global time source it gets the leap_second option if known (none
> otherwise). When the day the leap second needs to be applied is reached,
> the nodea
> applies the specified correction at the end of the day. having 23:59:58 or
> 23:59:60 as the last second of the day.
>
> ---
>
> issue: why era?
> severity: med
>
> Why have an era counter that confuses everything? Why not simply a 64-bit
> epoch value?
>
> XV: The era counter in NTP is a 32bit. We use 8bit instead as we think
> this spec can be updated after 136*256 years.
> The seconds field wraps every 136 years. It will wrap in Feb 2036 moving
> from era 0 to era 1.
> makes sense?
>
> ---
>
> issue: fraction field?
> severity: low
>
> THere is some inconsistency in naming of fields. The term "fraction" is
> confusing. The field is described as:
>
> A 32-bit unsigned integer containing the number of picoseconds elapsed
> after the last entire second at the beginning of the timeslot at which the
> CoAP Response (e.g. Join Response) is processed.
>
> but also as
>
> The fraction field provides synchronization precisions in the order of
> hundreds of picoseconds.
>
> why hundreds of picoseconds, and not picoseconds?
>
> XV: this is the same approach as for NTP. The fraction represents 1/2^32
> seconds giving a 232-ps resolution.
>
> ---
>
> issue: reorganizing Global Time Extension to the Join Response
> severity: low
>
> The last 3 paragraphs of that section should be merged into the bullet
> list of fields.
>
> XV: thanks. We had doubts if this was more clear or was adding too much
> text to the presentation of the fields. We will consider that.
>
>
> 2018-03-01 21:58 GMT+01:00 Thomas Watteyne <thomas.watte...@inria.fr>:
>
>> As promised :-)
>>
>> draft-vilajosana-6tisch-globaltime-00 provides an important feature for
>> a synchronized network.
>> It is a simple solution; the draft is easy to follow.
>>
>> A number of issues below:
>>
>> ---
>>
>> issue: confused about time source
>> severity: low
>>
>> The "Global Time Source" section starts with a paragraph which suggests a
>> particular node in the network has a global time knownledge.
>> Yet, the paragraph after, is seems as if only the JRC can play that role.
>> That is entirely OK, but I would just merge those paragraphs and say that
>> the JRC has some global time knowledge.
>>
>> ---
>>
>> issue: synchronization between JRC and network
>> severity: high
>>
>> When the JRC is co-located with the DAGroot, it's "easy" for it to konw
>> both the network and global time with nanosecond accuracy.
>> But the JRC can be a logical entity locate far from the 6TiSCH network.
>> Something in the text needs to state that, and probably say that how the
>> JRC sync to the 6TiSCHnetwork is out of scope.
>>
>> ---
>>
>> issue: PTP?
>> severity: low
>>
>> Fig. 1 contains "PTP", which isn't reference anywhere in the text AFAICT.
>>
>> ---
>>
>> issue: byte ordering
>> severity: low
>>
>> Section "Global Time Extension to the Join Response" defines the fact
>> that "The 5-byte ASN is carried in network byte order". But isn't byte
>> ordering something that is already specified by CBOR?
>>
>> ---
>>
>> issue: reference of time mapping
>> severity: medium
>>
>> The specification basically defines a format to say "at ASN X, global
>> time is Y".
>> In theory, what ASN is used is irrelevant, so I wuoldn't mandate for that
>> to be "at which the CoAP Response (e.g, Join Response) is processed".
>> You could also simply specify what time it was at ASN 0.
>>
>> ---
>>
>> issue: confusion about 3 timestamps
>> severity: medium
>>
>> The format defined in "Global Time Extension to the Join Response"
>> contains 3 timestamps: ASN, timestamp in seconds, timestamp in ps.
>> I don't understand the description of the latter two. Why not simply "at
>> the beginning of that ASN, this is the epoch (possibly split in s and ps)"
>>
>> ---
>>
>> issue: freshness of time?
>> severity: medium
>>
>> I don't understand the logic of adding a "the number of days of freshness
>> of the assigned global time information".
>> Time is the one thing that advanced at 60min per hour, no matter what :-)
>> What's the idea behind this?
>> The term "freshness" for sure doesn't seem the right one.
>>
>> ---
>>
>> issue: default freshness value
>> severity: low
>>
>> after the following sentence:
>> Optionally, an unsigned word lease value indicating the number of days of
>> freshness of the assigned global time information.
>> you should specify that no value means infinite freshness
>>
>> ---
>>
>> issue: what about drift?
>> severity: high
>>
>> the specification is pretty obsessed about leap seconds, a cool thing for
>> sure, but not the most important problem.
>> IMO, the most important problem is that the root of the TSCH network
>> drifts relative to UTC.
>> You have 2 options:
>>     - you say the root is always sync'ed, i.e. 0 drift. That's hard.
>>     - you provide a mechanism which accounts for drift in your format
>>     - you leave everything as-is, but force your nodes to refresh their
>> time periodically
>> To be discussed.
>>
>> ---
>>
>> issue: unit and width confusion for leap second handling
>> severity: low
>>
>> A 16-bit unsigned integer containing an offset in **days** to the
>> beginning of the day (0 h UTC) when the next leap second must be applied.
>> I assume **days** should be seconds?
>>
>> If that is the case, there are 86400 seconds in a day, a 16-bit number
>> will not be enough.
>>
>> Are leap seconds always applied at exact second boundaries?
>>
>> ---
>>
>> issue: why era?
>> severity: med
>>
>> Why have an era counter that confuses everything? Why not simply a 64-bit
>> epoch value?
>>
>> ---
>>
>> issue: fraction field?
>> severity: low
>>
>> THere is some inconsistency in naming of fields. The term "fraction" is
>> confusing. The field is described as:
>>
>> A 32-bit unsigned integer containing the number of picoseconds elapsed
>> after the last entire second at the beginning of the timeslot at which the
>> CoAP Response (e.g. Join Response) is processed.
>>
>> but also as
>>
>> The fraction field provides synchronization precisions in the order of
>> hundreds of picoseconds.
>>
>> why hundreds of picoseconds, and not picoseconds?
>>
>> ---
>>
>> issue: reorganizing Global Time Extension to the Join Response
>> severity: low
>>
>> The last 3 paragraphs of that section should be merged into the bullet
>> list of fields.
>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
>
> --
> Dr. Xavier Vilajosana
> Wireless Networks Lab
>
> *Internet Interdisciplinary Institute (IN3)Professor*
> (+34) 646 633 681 <+34%20646%2063%2036%2081>
> xvilajos...@uoc.edu <usu...@uoc.edu>
> http://xvilajosana.org
> http://wine.rdi.uoc.edu
> Parc Mediterrani de la Tecnologia
> Av Carl Friedrich Gauss 5, B3 Building
> <https://maps.google.com/?q=Av+Carl+Friedrich+Gauss+5,+B3+Building+08860+Castelldefels+(Barcelona).+Catalonia.+Spain&entry=gmail&source=g>
> 08860 Castelldefels (Barcelona). Catalonia. Spain
> <https://maps.google.com/?q=Av+Carl+Friedrich+Gauss+5,+B3+Building+08860+Castelldefels+(Barcelona).+Catalonia.+Spain&entry=gmail&source=g>
> [image: Universitat Oberta de Catalunya]
> ­
>



-- 
________________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Analog Devices
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
________________________________________
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to