Re: [6lo] Last Call: <draft-ietf-6lo-deadline-time-03.txt> (Packet Delivery Deadline time in 6LoWPAN Routing Header) to Proposed Standard

[Tal Mizrahi <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]> wrote:
>
>> Hi Tal,
>>
>> On Dec 23, 2018, at 3:49 AM, Tal Mizrahi <[e-mail]>
>> 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
>>
>>