Re: [Ntp] [6lo] Last Call: <draft-ietf-6lo-deadline-time-03.txt> (Packet Delivery Deadline time in 6LoWPAN Routing Header) to Proposed Standard
Charlie Perkins <charles.perkins@earthlink.net> Mon, 11 February 2019 14:14 UTC
Return-Path: <charles.perkins@earthlink.net>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3B912008A; Mon, 11 Feb 2019 06:14:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net
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 N3nwxL-ENM5m; Mon, 11 Feb 2019 06:14:42 -0800 (PST)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 481F8126F72; Mon, 11 Feb 2019 06:14:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1549894482; bh=AcM6FdgORjhOveCcMBrbaOUnYz+wMs3g/PYA kqLMnwI=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=gKEB8IXbULNG1DyppFYBP7mYYdbXs493O KTbNmw7wOeTBaqdU6esLUiTYPKYyJuYD3VEm5evMUOkCnkkcAM5k9XVAnxnBNdPkrm5 t+/5LS0nWErW7q/O+km/Ytc9snu0jgNWbC+Ma6SX1+PF4gKMCuVKUi2P5ucz+i4T4cP Imok/bF7iiFPdhJjTe6jPWSJMs2Qv9tXfLKqYlWuKuItMQZcPZLUoXWWupZp91uNnho NiDl6pOaqwfrILyaYhzc4UZlIWVr9QI56cSZKFHa3uPIR4OccjeNlcfBoACzs7UoDvU iwCBq/kkFv+j5jtXsL8qPzDxlbeMRGi3ssvEI22kQ==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=jQonkwsbL6PuSx2pczlGMu4h/TF8YfEVcp7fF3cZ6c6+dTU8tLWKkSaz8WhLDYSWqPu4+FXxU5zSn0Pug8HJ0qOvYfjP05jCgFHS7m1SM3ooOtaEHOp1jfb71N2UNvNoWa5zHNVt69hrqyd1cXMQYfoVrRlLCuXAQ/Kmxzxinbb4qzwYtnKjMyDDAogoI5BH27AOxYiXZ/4zydvndbDT5LFJXVgHCC/EdjDFaVTZBfKNHD31AZV9QYyDzR9cqKKtke5a27nQYL24vaF8HjkL5Lse33qGv9vTY3vDcs+Us9vuUTRLfmeybzRdQPr3csI9nnDm+5woBSiVFMQjV9BO7g==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from <charles.perkins@earthlink.net>) id 1gtCM5-000CLb-3I; Mon, 11 Feb 2019 09:14:41 -0500
To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Cc: "draft-ietf-6lo-deadline-time@ietf.org" <draft-ietf-6lo-deadline-time@ietf.org>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, IETF <ietf@ietf.org>, "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>, IETF-Announce <ietf-announce@ietf.org>
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>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <73109dcb-915c-a826-6aef-6a14f858a8dd@earthlink.net>
Date: Mon, 11 Feb 2019 06:14:38 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CABUE3XmQ7LDwL6HyA0QZaL1=QBSUaXQE3b=hCO0vp23irct=Ag@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------B75AE5445EEB697EF10DE626"
Content-Language: en-US
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c95579d7b72e0d46e3ef7d8d953048843b5350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/mH54SaXhXNMCUXe3UAHXi2uSUzk>
X-Mailman-Approved-At: Mon, 11 Feb 2019 07:06:49 -0800
Subject: Re: [Ntp] [6lo] Last Call: <draft-ietf-6lo-deadline-time-03.txt> (Packet Delivery Deadline time in 6LoWPAN Routing Header) to Proposed Standard
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2019 14:14:45 -0000
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 <mailto: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 <mailto:Suresh@kaloom.com>> wrote: >> >> Hi Tal, >> >>> On Dec 23, 2018, at 3:49 AM, Tal Mizrahi >>> <tal.mizrahi.phd@gmail.com >>> <mailto: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 list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo
- Re: [Ntp] Last Call: <draft-ietf-6lo-deadline-tim… Tal Mizrahi
- Re: [Ntp] Last Call: <draft-ietf-6lo-deadline-tim… Tal Mizrahi
- Re: [Ntp] Last Call: <draft-ietf-6lo-deadline-tim… Suresh Krishnan
- Re: [Ntp] [6lo] Last Call: <draft-ietf-6lo-deadli… Lijo Thomas
- Re: [Ntp] Last Call: <draft-ietf-6lo-deadline-tim… Tal Mizrahi
- Re: [Ntp] Last Call: <draft-ietf-6lo-deadline-tim… Charlie Perkins
- Re: [Ntp] Last Call: <draft-ietf-6lo-deadline-tim… MORTON, ALFRED C (AL)
- Re: [Ntp] [6lo] Last Call: <draft-ietf-6lo-deadli… Charlie Perkins
- Re: [Ntp] [6lo] Last Call: <draft-ietf-6lo-deadli… Tal Mizrahi