IETF Logo Mail Archive

Re: [dtn] BPbis - time units

Jeremy.Mayer@dlr.de Wed, 29 July 2020 07:11 UTC

Return-Path: <Jeremy.Mayer@dlr.de>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B363A106F for <dtn@ietfa.amsl.com>; Wed, 29 Jul 2020 00:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 77OnGFt4BieT for <dtn@ietfa.amsl.com>; Wed, 29 Jul 2020 00:11:22 -0700 (PDT)
Received: from mailin.dlr.de (mailin.dlr.de [194.94.201.12]) (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 2C0F13A106D for <dtn@ietf.org>; Wed, 29 Jul 2020 00:11:21 -0700 (PDT)
IronPort-SDR: CSvV02gCCYcZWMhH6ZGm5MEXcKO3cTKfbW1CfAuH9ODavAQBFG1EwPZLnhfq1+/6kYWFFSDQPq 111eSEBZtpJQ==
X-IPAS-Result: A2FYAAAxICFf/xeKuApgHAEBAQEBAQcBARIBAQQEAQFAgTgFAQELAYEiAYFhFIEzCpVLmg+BdAkLAQEBAQEBAQEBBwEYAQoMBAEBAoRKAoIjJTYHDgIDAQEBAwIDAQEBAQYBAQEBAQEFBAEBAoYMOQyCNyJ6gQMBAQEBAQEBAQEBAQEBAQEBAQEBFgJDVRIBAR0BAQEBAwEBK0ELEAIBCBEEAQEBLicLHQgBAQQBDQUIgx+BfoENriN0gTSFUoUWBoE4AY8ggRGDED6CXAEBAoFihXEEmUScOQeBWpp3KpFEjiorhSOMTJ8cAgQCBAUCFYFaDFKBLXFPgmlQFwINjicaiGKFQnQCAQEBMgIGAQcBAQMJj06BEQEB
IronPort-PHdr: 9a23:2kcf6R8ioS+O4/9uRHKM819IXTAuvvDOBiVQ1KB+0+gUIJqq85mqBkHD//Il1AaPAdyFrawfwLOO4+jJYi8p2d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6JvjvGo7Vks+7y/2+94fcbglVhTexe7J/IRu5oQnMqsUbgpZpJ7osxBfOvnZGYfldy3lyJVKUkRb858Ow84Bm/i9Npf8v9NNOXLvjcaggQrNWEDopM2Yu5M32rhbDVheA5mEdUmoNjBVFBRXO4QzgUZfwtiv6sfd92DWfMMbrQ704RSiu4qF2QxLulSwJNSM28HvPh8JwkqxVvQ6hqRJ8zY7aYo6VNeZxcazGcNwAWWZBXNxcWzBdDo68aYYEEuoPPfxfr4n4v1YDqh+wChe2BOzxzz9JhmX606og3OUhDw7GxhctEM8KsHTOttn6KbkdXPmzwaLVwjrNc+lY1i3h6IjUbB8hu/eMUKp+fMfNy0QhGR3Jg0ifpIH4Iz+Y2OQDvmiF4uduS+6hhG4pphxxrzWvyMoihYnEi4wIxl7K+yt0wpg5KNm3RUNnZ9OvDZVetyafN4RsQ8MiRXlluCckxb0at563Zi8KyI4oxxPZdveJcJCI7wr+WOqNOzt0mXFodb2lixqv/0WtyffwWte63VpSsyZIkMfAumoT2xDO8MSLV/lw80a71TqS0Q3Y9/tKLloulaXBLp4s2rswlp0OvkvdBiL2g0D2jLOOdkUj5+io9/zrYrX4qZ+YMI95kg/wPKIglMKwAeo2Mg8AUWuc9+qmyrHu80L3T7RUg/Esk6nZtozaJd4BqaKjHgBV1pwj5wyiADi4yNgYnH8HI0xZeB+fkoTlJ0vCLO37APqwmVigjTlmyvPcMrH/DJjBNn3Dn63gfbZ55U5c0g0zzdVH6pxQFL4BOuz8WkrxtdDCCRE2KQy1zPj9CNhmy4weXXiPDrWEP6zMqVOI/P4gI/GQZI8JvzbwM+Qq6OT1gn8+glIdYaio3ZoNZHC/BPRmLF2TYWDwjdcZDWcKog0+QfTxiFKeVj5Te2qyU7gg6T0hE42mEJ3DRoSzj7yA0ye7HoVba29aBlCOCXfoc5+IW/EWZyKJOMBtiDMEVb+/S4I6yB6usRX1y6B7IebO+y0Xq47j1NZv6+3UjxEy+iR+D96B3GGVU2F0gmQISicr06Bjp0xw0VaD3rZkg/xWD9BT4OlJUghpfaLbmrhxAtr1ch7Tf5GOUlnwBp3yGjo2Us53yJkEflx5FtStjkWfhyiyB/kTnqeCQpMz7IrQ2nHrLIB8xmrIkq47gA91bNFIMDjypKNl+g3CQavAgkiDv6qub+IQ0Xiepy+40WOSsRQAA0ZLWqLfUCVHaw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.75,409,1589234400"; d="scan'208,217"; a="39420756"
From: Jeremy.Mayer@dlr.de
To: cabo@tzi.org, scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org
CC: dtn@ietf.org
Thread-Topic: [dtn] BPbis - time units
Thread-Index: AdZlRE16z8ydhrAuQoeEqKCZTB9oagAFrdGAAAa4fEk=
Date: Wed, 29 Jul 2020 07:11:18 +0000
Message-ID: <10b6be3b53a1460d8b1c53b0ba14099f@dlr.de>
References: <9f0460a88aab4e29bc0d12347b27613a@jpl.nasa.gov>, <2D9743FA-7D23-444F-8D8C-F7B04CDCC010@tzi.org>
In-Reply-To: <2D9743FA-7D23-444F-8D8C-F7B04CDCC010@tzi.org>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tm-snts-smtp: C20F450C41FF15D7A15AFA9968E978D72AA47AFEE28EBA5BF29BDB062D5F76D22000:8
Content-Type: multipart/alternative; boundary="_000_10b6be3b53a1460d8b1c53b0ba14099fdlrde_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/iazqVx2obv3bt3hbI4NU084_51s>
Subject: Re: [dtn] BPbis - time units
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2020 07:11:25 -0000

Hi,

I think we need to allow some flexibility with regards to the expression of time units. For many applications, it should suffice to keep everything in milliseconds (keeping in mind that millisecond-based times also necessitate internal timekeeping capability with a similar accuracy. However, in long-delay/bandwidth-constrained applications, there may not be any real requirement to have millisecond-accuracy time fields/time-keeping.


Therefore, I propose (apologies in advance) that we use both: tag 1 can be a standard unix-based timestamp (in seconds), used for long-delay applications. Otherwise, times can be represented with tag 1001, key (-3,-18) as reference in Carstens CBOR timekeeping draft (https://www.ietf.org/id/draft-bormann-cbor-time-tag-03.txt) for additional flexibility in unit expression, with the slight overhead that may arise.


Thanks,

Jeremy

________________________________
From: dtn <dtn-bounces@ietf.org> on behalf of Carsten Bormann <cabo@tzi.org>
Sent: Wednesday, July 29, 2020 7:47:45 AM
To: Burleigh, Scott C (US 312B)
Cc: dtn@ietf.org
Subject: Re: [dtn] BPbis - time units

On 2020-07-29, at 03:09, Burleigh, Scott C (US 312B) <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org> wrote:
>
> Hi.  At IETF-108 there was discussion on whether BP time fields (e.g., bundle creation time, lifetime, bundle age) should be denominated in seconds, milliseconds, microseconds, or nanoseconds.  Version 26 of the BPbis I-D (now posted) revises all time field definitions to be denominated in milliseconds.

Note that CBOR has a choice of different time formats (tag 1, tag 1001), so if you want to provide a choice, you could allow the use of these in addition to assigning a default meaning to naked integers.  (These have a different epoch, but that is just a matter of subtracting a constant value; the representation needs one bit more which is making a difference between 2106 and 2030 next for whole seconds.)  Until 2106, tag 1 is shorter (6 bytes in total) than a naked integer in milliseconds (9 bytes).

(I don’t have an opinion on the actual question, but here is some data for that.)

Grüße, Carsten

_______________________________________________
dtn mailing list
dtn@ietf.org
https://www.ietf.org/mailman/listinfo/dtn

v2.23.0 | Report a Bug | By Email