|
Hello Tal and all,
I thought it would be better to make the length fields count
nibbles instead of octets, since we don't have EXP any more. A
4-bit length field then allows up to 64 bits precision, which
should be enough for most purposes.
Do you think that would be O.K.?
Regards,
Charlie P.
On 2/11/2019 5:13 AM, Tal Mizrahi
wrote:
Hi Charlie,
Thanks for reviewing the packet timestamp draft.
Your suggestion makes sense to me.
Just a minor question regarding your example below ("If
we had a 12-bit timestamp format..."):
The DTL and OTL fields specify the length of the DT and
OT fields in octets, and therefore the length of DT and OT
is a multiple of 8 bits. So the DT and OT can't be 12 bits
long, right?
Cheers,
Tal.
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.
Hi Tal,
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.
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
6lo@xxxxxxxx
https://www.ietf.org/mailman/listinfo/6lo
|
