Hello Tal and all,
I have read draft-ietf-ntp-packet-timestamps-05.txt. This is an
excellent document.
Our previous timestamp format in draft-ietf-6lo-deadline-time-03.txt
offers a lot of flexibility in a compact format, but maybe that much
flexibility is not needed. I would like to suggest that we use the
timestamp template in draft-ietf-ntp-packet-timestamps-05.txt, but with
possibly fewer bits than the 32-bit NTP format. As I understand it,
that format divides the available number of bits evenly between integral
seconds and fractional seconds. So, for instance, if we had an 8-bit
timestamp format, that would allow for 16 seconds total duration
denominated in sixteenths of a second (i.e., time units of about 64
milliseconds). That would be pretty good for most purposes. If we had
a 12-bit timestamp format, that would allow for 64 seconds denominated
in units of approximately 16 milliseconds. If the optional Origination
Time is included, then we would mandate that the OT has the same time
unit as the DT. In this case, that translates to meaning that the
number of bits for fractional seconds is the same, but we could allow
the OT to have fewer bits for the integer number of seconds.
If we go this way with predefined time designations according to the NTP
draft format, we don't need the Exp field. It is also possible that an
asymmetric number of bits would be considered to satisfy the specified
NTP-related format (i.e., not the same number of bits for fractional
seconds as for integer seconds). In that case, we could use a new field
to locate the binary point. We can make the definitions so that this new
information still fits within the space of the Deadline-6LoRHE format.
One could argue that this new field is analogous to the Exp field.
draft-ietf-ntp-packet-timestamps-05.txt mandates certain details in the
Security Considerations which we will need to obey. It also suggests
inclusion of material about synchronization. I think we also have to do
consider doing that.
What do you think?
Regards,
Charlie P.
On 1/3/2019 5:02 AM, Tal Mizrahi wrote:
Hi Suresh, authors,
>> I would suggest to follow the timestamp specification template of
Section
>> 3 in draft-ietf-ntp-packet-timestamps-05.
>I think the semantics of the DT and OT fields are a bit different
from the
>NTP packet timestamps and there are also resource constraints in the
>6lo world that might make the 64 bit formats expensive. I will let the
>authors and the WG comment further on this.
I agree that the NTP timestamp format does not fit here.
My comment was that DT and OT should be defined according to the
timestamp specification template (section 3 in the packet timestamp
draft).
This is a *generic template* for defining all kinds of timestamp formats.
The template was defined in order to make sure that when you define a
timestamp format you do not forget important details.
Just to clarify, I am not suggesting to change the timestamp formats
of DT and OT, but only to specify them in a clear and unambiguous manner.
Thanks,
Tal.
On Wed, Jan 2, 2019 at 11:00 PM Suresh Krishnan <[email protected]
<mailto:[email protected]>> wrote:
Hi Tal,
On Dec 23, 2018, at 3:49 AM, Tal Mizrahi
<[email protected] <mailto:[email protected]>> wrote:
Hi,
I am not a 6lo native, but I reviewed the draft specifically from
a timestamp formatting perspective.
In the NTP working group we currently have a draft in WGLC that
presents guidelines for defining timestamp formats.
https://tools.ietf.org/html/draft-ietf-ntp-packet-timestamps-05
I believe that the definitions of the timestamps (DT and OT)
in draft-ietf-6lo-deadline-time should be more detailed. For
example, aspects about the epoch and the potential effect of leap
seconds are currently not described in the current draft.
Good point. Authors, can you add some further descriptive text
around these fields.
I would suggest to follow the timestamp specification template of
Section 3 in draft-ietf-ntp-packet-timestamps-05.
I think the semantics of the DT and OT fields are a bit different
from the NTP packet timestamps and there are also resource
constraints in the 6lo world that might make the 64 bit formats
expensive. I will let the authors and the WG comment further on this.
Thanks
Suresh
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
