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

From: Suresh Krishnan <[email-masked]>
Date: Wed, 2 Jan 2019 21:00:48 +0000

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: Thu, 3 Jan 2019 15:02:32 +0200

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

> Hi Tal,
>
> On Dec 23, 2018, at 3:49 AM, Tal Mizrahi <[email-masked]>
> wrote:
>
> Hi,
>
> In the NTP working group we currently have a draft in WGLC that presents
> guidelines for defining timestamp formats.
> 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.
>
>
> 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: Abdussalam Baryun <[email-masked]>
Date: Fri, 4 Jan 2019 01:13:47 +0200

I agree with specifying time semantics with more details as Tal suggested
(see below),

Furthermore, I suggest that we can add another delivery deadline time known
as the interval time. The interval time is the maximum time before another
packet of the same type as the received one from the same originator should
be received. IMO it can be more useful in LLNs, as it can be useful in
MANETs [RFC5497].

So suggest the draft replaces 'packet delivery deadline' with 'packet
delivery validity time', so that there can be two 'delivery deadlines' of
6LoWPAN routing header packets, one is the validity time and the second is
interval time (or maybe one of them can be optional).

AB

On Mon, Dec 10, 2018 at 2:27 PM The IESG <[email-masked]> wrote:

>
> The IESG has received a request from the IPv6 over Networks of
> Resource-constrained Nodes WG (6lo) to consider the following document: -
> 'Packet Delivery Deadline time in 6LoWPAN Routing Header'
>   <draft-ietf-6lo-deadline-time-03.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2018-12-24. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document specifies a new type for the 6LoWPAN routing header
>    containing the delivery deadline time for data packets.  The deadline
>    time enables forwarding and scheduling decisions for time critical
>    IoT M2M applications that need deterministic delay guarantees over
>    constrained networks and operate within time-synchronized networks.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>     draft-ietf-6tisch-terminology: Terms Used in IPv6 over the TSCH mode
> of IEEE 802.15.4e (None - IETF stream)
>
>
>
>

---

From: "Lijo Thomas" <[email-masked]>
Date: Thu, 3 Jan 2019 17:38:52 +0530

Hi Tal,

Thanks for your comments.

The scope of our deadline-time draft is confined to a resource constrained 6lo network and hence specifies the DT/OT time representation that is suited for such networks.

The draft specifies an encoding method for expressing the deadline time of a packet for its transmission over a resource constrained 6lo network. So really, the interpretation of Time Unit is scoped to the underlying network technology and the definition(s) of time it provides as specified by the underlying network. So we feel the <draft-ietf-ntp-packet-timestamps-05> won’t be applicable to our case.

For providing more clarity as indicated by Suresh Krishnan too, we will add appropriate text in the next revision.

Happy to receive further comments if any;

Thanks & Regards,

Lijo Thomas 

 <https://www.codetwo.com/> 

From: 6lo <[email-masked]> On Behalf Of Tal Mizrahi
Sent: 23 December 2018 14:20
To: [email-masked]
Cc: [email-masked]; [email-masked]; Samita Chakrabarti <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; IETF-Announce <[email-masked]>
Subject: Re: [6lo] Last Call: <draft-ietf-6lo-deadline-time-03.txt> (Packet Delivery Deadline time in 6LoWPAN Routing Header) to Proposed Standard

Hi,

Thanks,

Tal.

 

On Mon, Dec 10, 2018 at 2:27 PM The IESG <[email-masked] <mailto:[email-masked]> > wrote:

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] <mailto:[email-masked]>  mailing lists by 2018-12-24. Exceptionally, comments may be
sent to [email-masked] <mailto:[email-masked]>  instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

The document contains these normative downward references.
See RFC 3967 for additional information: 
    draft-ietf-6tisch-terminology: Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e (None - IETF stream)

------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
------------------------------------------------------------------------------------------------------------