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

[Charlie Perkins <[e-mail]>]

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 
> <[e-mail] <mailto:[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] <mailto:[e-mail]>> wrote:
>>
>>         Hi Tal,
>>
>>>         On Dec 23, 2018, at 3:49 AM, Tal Mizrahi
>>>         <[e-mail]
>>>         <mailto:[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
>>
>
> _______________________________________________
> 6lo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lo