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

From: Charlie Perkins <[email-masked]>
Date: Fri, 8 Feb 2019 18:25:18 -0800

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

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 11 Feb 2019 15:13:24 +0200

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-masked]> wrote:

> Hello Tal and all,
>
> I have read draft-ietf-ntp-packet-timestamps-05.txt.  This is an excellent
> document.
>
> 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.
>
> 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.
>
> >I think the semantics of the DT and OT fields are a bit different from
> the
> My comment was that DT and OT should be defined according to the timestamp
> specification template (section 3 in the packet timestamp draft).
> 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-masked]> wrote:
>
>> Hi Tal,
>>
>> On Dec 23, 2018, at 3:49 AM, Tal Mizrahi <[email-masked]>
>> 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.
>> 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
>> 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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 11 Feb 2019 13:55:12 +0000

Hi Tal and Charlie, (removing IETF-announce)
just following along...
From: ntp [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Monday, February 11, 2019 8:13 AM
To: Charlie Perkins <[email-masked]>
Cc: [email-masked]; [email-masked]; IETF <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Suresh Krishnan <[email-masked]>; IETF-Announce <[email-masked]>
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,

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-masked]<mailto:[email-masked]>> 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.

>I think the semantics of the DT and OT fields are a bit different from the

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-masked]<mailto:[email-masked]>> wrote:
Hi Tal,

On Dec 23, 2018, at 3:49 AM, Tal Mizrahi <[email-masked]<mailto:[email-masked]>> 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

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 11 Feb 2019 06:14:38 -0800

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:
> 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-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hello Tal and all,
>
>     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.
>
>>     timestamp specification template (section 3 in the packet
>>     timestamp draft).
>>     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-masked] <mailto:[email-masked]>> wrote:
>>
>>         Hi Tal,
>>
>>>         <[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>
>>>         Hi,
>>>
>>>         In the NTP working group we currently have a draft in WGLC
>>>         that presents guidelines for defining timestamp formats.
>>>         example, aspects about the epoch and the potential effect of
>>>         leap seconds are currently not described in the current draft.
>>
>>>         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-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 14 Feb 2019 10:48:37 +0200

Hi Charlie,

Gotcha.
That sounds okay.

Cheers,
Tal.

On Mon, Feb 11, 2019 at 4:14 PM Charlie Perkins <
[email-masked]> wrote:

> 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.
>
>> timestamp specification template (section 3 in the packet timestamp draft).
>> 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.
>>
>>
>>
>>
> 6lo mailing [email-masked]://www.ietf.org/mailman/listinfo/6lo
>
>