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

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Thu, 14 February 2019 08:48 UTC

Return-Path: <tal.mizrahi.phd@gmail.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F7E12D7F8; Thu, 14 Feb 2019 00:48:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N67hAsmHXiU3; Thu, 14 Feb 2019 00:48:49 -0800 (PST)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6768A13106D; Thu, 14 Feb 2019 00:48:49 -0800 (PST)
Received: by mail-qt1-x82a.google.com with SMTP id y20so5909424qtm.13; Thu, 14 Feb 2019 00:48:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q5ydGUDWO9l4vJDLkfEF4gfP6OfMNODtm+91rhv2MJk=; b=sGSmgO62+iG0StfrurUNDUVH6Fq2L/FSrDR/jIa3xBu1e//D4hE9qLJ7e4Xl1G7loO gU3ECbf/lX9nlCq+eG2q7HrNpf+2Vp3MjkDLwLfzj+H6V5+hD/AnW/65D51h0EpM+AkP +x5nrm9ZKRxgnCDS6Ehzt4L5x4dAhDIFQbh6vCeUolwTcfbsbM43z7ymfJaS+Bw1DlhE rwknfgLhx5JJfH3x2HKbqxDl4yo1TB73Dn0GNdPM199dwfq1goeTBKceNvQMBivKjFwM 4kmUTWZj3LjrLbkWipAh2ROZaL4vE604fhvzvq/5xExj+lY/X+oFIGXQ0qeEsGRGVajj mziw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q5ydGUDWO9l4vJDLkfEF4gfP6OfMNODtm+91rhv2MJk=; b=TkxJB9MgJj31J3QduCT+FBTWPm2BuLeXLT73a8CBj4dFNBLbROeTnVznwbWRwFv2Fm V5Xs+bg+WJPHkZGycx389E8Usm9lspVCDNaJVj/4P9uIKHhBSExYbDZk6J0gEkl1utBo g52B8OrmHNavLFtfJw3L3uhTOmqgbdTB9s/+Tf97YkBjDAZfio4yxdVW+Q41zYvdLScj 9kOU0uFfowiveKoihWNrbzOlQcWNjn9vLjGHVNpxsTwvF1KVk8EeJDeIIWBB4v77/AUl T0Rhc067ExbY9xOz0QcHSUwjsJs16gprFzoROxfzUq4UIWxmCNjyvFBpVg6+RXxlGRQi Icsw==
X-Gm-Message-State: AHQUAublLJcgqU99w9PPgyEAOdCML2tXS4YS7BA/PgkSqWSBOg5PtCS7 DENh+ZZ8iclgT6Gs5gCOJW1HigpDJqT/j/z2xLzOqpVm
X-Google-Smtp-Source: AHgI3Ia9QRjncVlxNIKmrD5IBn5b/3GF0bOndlvAyoa2Wjr8hRH7NQTH/0lGp+Q6Q7qbOswWtrl11z9Wn6ygdusby78=
X-Received: by 2002:ac8:3341:: with SMTP id u1mr2004957qta.58.1550134128399; Thu, 14 Feb 2019 00:48:48 -0800 (PST)
MIME-Version: 1.0
References: <154444480037.17333.5127536482994262799.idtracker@ietfa.amsl.com> <CABUE3XnQSi9rJnN2pxp2ZmmMAF4-aTgZ3eFeuWgj7uDWkZDoHw@mail.gmail.com> <0277B06D-060A-44AB-BA7A-C02F3C6E5021@kaloom.com> <CABUE3XmL_XERozG96bCboxwsbSFWjxvbwyupvs+CjvFA8eR59Q@mail.gmail.com> <22cec0be-76df-9fed-45d9-48769d662506@earthlink.net> <CABUE3XmQ7LDwL6HyA0QZaL1=QBSUaXQE3b=hCO0vp23irct=Ag@mail.gmail.com> <73109dcb-915c-a826-6aef-6a14f858a8dd@earthlink.net>
In-Reply-To: <73109dcb-915c-a826-6aef-6a14f858a8dd@earthlink.net>
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Thu, 14 Feb 2019 10:48:37 +0200
Message-ID: <CABUE3XkHTyrzAj-iW-GrBZ3TL=zht6ciauawzL+Nur6eOggS9Q@mail.gmail.com>
To: Charlie Perkins <charles.perkins@earthlink.net>, "draft-ietf-6lo-deadline-time@ietf.org" <draft-ietf-6lo-deadline-time@ietf.org>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>
Cc: "ntp@ietf.org" <ntp@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "ntp-chairs@ietf.org" <ntp-chairs@ietf.org>, Suresh Krishnan <Suresh@kaloom.com>
Content-Type: multipart/alternative; boundary="00000000000013d8e20581d6ba40"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/-uxaZ2PVoiW1j4nA5NT3-N3R85U>
Subject: Re: [6lo] Last Call: <draft-ietf-6lo-deadline-time-03.txt> (Packet Delivery Deadline time in 6LoWPAN Routing Header) to Proposed Standard
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2019 08:48:53 -0000

Hi Charlie,

Gotcha.
That sounds okay.

Cheers,
Tal.

On Mon, Feb 11, 2019 at 4:14 PM Charlie Perkins <
charles.perkins@earthlink.net> wrote:

> 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 <
> charles.perkins@earthlink.net> 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 <Suresh@kaloom.com>
>> wrote:
>>
>>> Hi Tal,
>>>
>>> On Dec 23, 2018, at 3:49 AM, Tal Mizrahi <tal.mizrahi.phd@gmail.com>
>>> 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 list6lo@ietf.orghttps://www.ietf.org/mailman/listinfo/6lo
>
>