Hi Tal and Charlie, (removing IETF-announce)
just following along...
From: ntp [mailto:[email protected]] On Behalf Of Tal Mizrahi
Sent: Monday, February 11, 2019 8:13 AM
To: Charlie Perkins <[email protected]>
Cc: [email protected]; [email protected]; IETF
<[email protected]>; [email protected]; [email protected]; [email protected]; Suresh
Krishnan <[email protected]>; IETF-Announce <[email protected]>
Subject: Re: [Ntp] Last Call: <draft-ietf-6lo-deadline-time-03.txt> (Packet
Delivery Deadline time in 6LoWPAN Routing Header) to Proposed Standard
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?
[acm]
Maybe Charlie meant the sum of DT and OT? = 24, divisible by 8
Charlie mentioned asymmetric lengths, too
(just had a first look at
https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-03 )
OTOH, maybe I need another cup of coffee,
Al
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dntp-2Dpacket-2Dtimestamps-2D05&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=4bnskZepRN5E4fDtyjJSzErjoNkK0-T162zuwSloT_M&s=6hVsSC47jguQsZDtFPNybEH4qIlUCg57CLiRkwmfyss&e=>
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
