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