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 > >
- [6lo] Last Call: <draft-ietf-6lo-deadline-time-03… The IESG
- Re: [6lo] Last Call: <draft-ietf-6lo-deadline-tim… Tal Mizrahi
- Re: [6lo] Last Call: <draft-ietf-6lo-deadline-tim… Suresh Krishnan
- Re: [6lo] Last Call: <draft-ietf-6lo-deadline-tim… Tal Mizrahi
- Re: [6lo] Last Call: <draft-ietf-6lo-deadline-tim… Abdussalam Baryun
- Re: [6lo] Last Call: <draft-ietf-6lo-deadline-tim… Lijo Thomas
- Re: [6lo] Last Call: <draft-ietf-6lo-deadline-tim… Charlie Perkins
- Re: [6lo] Last Call: <draft-ietf-6lo-deadline-tim… Tal Mizrahi
- Re: [6lo] [Ntp] Last Call: <draft-ietf-6lo-deadli… MORTON, ALFRED C (AL)
- Re: [6lo] Last Call: <draft-ietf-6lo-deadline-tim… Charlie Perkins
- Re: [6lo] Last Call: <draft-ietf-6lo-deadline-tim… Tal Mizrahi