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.
On Sat, Feb 9, 2019 at 4:25 AM Charlie Perkins
<[email protected] <mailto:[email protected]>>
wrote:
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
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
