Re: [icnrg] Fwd: New Version Notification for draft-gundogan-icnrg-ccnx-timetlv-01.txt

Cenk Gündoğan <mail+ietf@gundogan.net> Wed, 11 March 2020 11:20 UTC

Return-Path: <mail+ietf@gundogan.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F433A174D for <icnrg@ietfa.amsl.com>; Wed, 11 Mar 2020 04:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (bad RSA signature)" header.d=gundogan.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 YZfYaAMPY5EC for <icnrg@ietfa.amsl.com>; Wed, 11 Mar 2020 04:20:08 -0700 (PDT)
Received: from mail.localdomain (trantor.gundogan.net [37.120.167.193]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259B63A174C for <icnrg@irtf.org>; Wed, 11 Mar 2020 04:20:08 -0700 (PDT)
Received: from localhost (unknown [141.22.28.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mail.localdomain (Postfix) with ESMTPSA id AF28030210 for <icnrg@irtf.org>; Wed, 11 Mar 2020 12:11:16 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gundogan.net; s=201712; t=1583925076; bh=1vG2Vjx1TrR745ghchTw7U7sXEVlACgDxHsVLW2q/FU=; h=References:From:To:Subject:In-reply-to:Date:From; b=EQ2ManjMSaY0x5P3Ui42ZETl+ZuuFcuWV++2OmlMc7hbM2p8hpZcLxbpR6reatRWy uFZmxRYTePYIiWNFaLvMTzuai/IiEkv4wwnXGBOhTM47SDyVyTAfSuyzS3mVdCUtJ3 LkIQ/+W0a/CKhhPYer4kdZU8Z71/VsHh3smcqh7SEBlxvzv56a03iiq+z6KOamhPUM VhDD1C/pM9taplyuQHnqQMEPnHFEAMANkxfCsNo/9D6g7jlQS6DQKH3pUFaWYZF2/9 ff0g3Tcz2VYf9eoJIL9UiivBCOhwNAEDI/LQBD3X6V1bv+BEB4ixMQYA/qlN5Y2Tk7 OO8YVUfP+fveQ==
References: <158377934751.5670.18125787139348726755@ietfa.amsl.com> <87zhcpbbfj.fsf@gundogan.net> <6D09B0D2-A191-4CD0-B0AA-6E0CEE8C6156@parc.com>
User-agent: mu4e 1.2.0; emacs 26.3
From: Cenk =?utf-8?B?R8O8bmRvxJ9hbg==?= <mail+ietf@gundogan.net>
To: icnrg@irtf.org
In-reply-to: <6D09B0D2-A191-4CD0-B0AA-6E0CEE8C6156@parc.com>
Date: Wed, 11 Mar 2020 12:20:04 +0100
Message-ID: <87o8t3rvdn.fsf@gundogan.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/eUly1c4D9xsV6kfI6uL_u-KGNak>
Subject: Re: [icnrg] Fwd: New Version Notification for draft-gundogan-icnrg-ccnx-timetlv-01.txt
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2020 11:20:10 -0000

Hello Marc,

On Tue, Mar 10 2020 at 07:09 +0100, Mosko, Marc wrote:

> I think this draft is very clear and easy to follow.  The only addition I would make is to include an appendix with a few test vectors, say 0, a subnormal, and a normal or two.  Or put them in the main text as examples.

There are a few numbers in section 4:
   o  Minimum subnormal number: 0 seconds
   o  Maximum subnormal number: ~0.054688 seconds
   o  Minimum normalized number: ~0.062500 seconds
   o  Maximum normalized numbers: [~3.46, ~3.72, ~3.99] years

we can put a few more into the appendix to show how the resolution
degrades with higher numbers. That would be a good addition to the
document.

>
> One question to consider is, would there be more possible time encodings beyond this?  Do we need a way to clearly distinguish between time encodings for fields, or is inferring the encoding based on the length acceptable?  I would probably rule out a nested encoding, as that is counter-productive when trying to introduce a 1 byte scheme.

+1 to ruling out the nested TLV approach.

Currently, there are only two TLVs that benefit from the compact
timestamp encoding: InterestLifetime and RCT (in relative time form).

For these, the currently defined, positive-only, 1-octet configuration
(exponent=5,mantissa=3,bias=-5) is IMO sufficient. Using the TLV-Length
as an indicator (L==1) has the advantage of being quite unobtrusive. It
is not very flexible and extensible, though (as you pointed out).

For future relative-time TLVs, we can also define another
(sign,exponent,mantissa,bias) configuration (for L==1), if they require
different properties, e.g., negative number support, microsecond
resolution .. I currently cannot think of a reasonable use case that
requires multiple configurations for a single relative-time TLV.

We could also opt for a flat structure: New InterestLifetime / RCT /
... upper-level TLVs that reside next to the original TLVs (guarded with
an exclusive or, since only one encoding for InterestLifetime / RCT /
... shall be used at the same time). This would require an update to the
message structure BNF ..

Cheers,
Cenk

>
> Marc
>
> On 3/9/20, 12:03 PM, "icnrg on behalf of Cenk Gündoğan" <icnrg-bounces@irtf.org on behalf of mail=2Bietf=40gundogan.net@dmarc.ietf.org> wrote:
>
>     Dear ICNRG,
>
>     we updated our CCNx Time TLV draft to include the following changes:
>
>     * we removed the previously included discussion on using a time base TLV
>       for (absolute) RecommendedCacheTime (RCT) TLVs in content objects. The
>       current approach interprets RCT as absolute (normal behavior) for UTC
>       timestamps (8 octets), and as relative for a compact timestamp (1
>       octet).
>
>     * we added an explicit configuration for exponent, mantissa, and bias to
>       Section 4. That configuration yields a milli second resolution for
>       lower time values and can also (with low resolution) reaches values
>       has high as ~4 years.
>
>     * we added a few alternatives to section 5 (CCNx protocol integration)
>       to provide more material for discussions. This topic needs to converge
>       to a distinct solution, though.
>
>     As always, any feedback is highly appreciated.
>
>     Cheers,
>     Cenk
>
>     On Mon, Mar 09 2020 at 19:42 +0100, internet-drafts@ietf.org wrote:
>
>     > A new version of I-D, draft-gundogan-icnrg-ccnx-timetlv-01.txt
>     > has been successfully submitted by Cenk Gundogan and posted to the
>     > IETF repository.
>     >
>     > Name:		draft-gundogan-icnrg-ccnx-timetlv
>     > Revision:	01
>     > Title:		An Alternative Delta Time encoding for CCNx using Interval Time from RFC5497
>     > Document date:	2020-03-09
>     > Group:		Individual Submission
>     > Pages:		8
>     > URL:            https://www.ietf.org/internet-drafts/draft-gundogan-icnrg-ccnx-timetlv-01.txt
>     > Status:         https://datatracker.ietf.org/doc/draft-gundogan-icnrg-ccnx-timetlv/
>     > Htmlized:       https://tools.ietf.org/html/draft-gundogan-icnrg-ccnx-timetlv-01
>     > Htmlized:       https://datatracker.ietf.org/doc/html/draft-gundogan-icnrg-ccnx-timetlv
>     > Diff:           https://www.ietf.org/rfcdiff?url2=draft-gundogan-icnrg-ccnx-timetlv-01
>     >
>     > Abstract:
>     >    CCNx utilizes Delta Time for a number of functions.  When using CCNx
>     >    in environments with constrained nodes and/or bandwidth constrained
>     >    networks, it is valuable to have a compressed representation of delta
>     >    time.  In order to do so, either accuracy or dynamic range has to be
>     >    sacrificed.  Since the current uses of delta time do not require both
>     >    simultaneously, one can consider a logarithmic encoding such as that
>     >    specified in RFC5497.  This document updates _CCNx messages in TLV
>     >    Format_ (RFC8609) to specify this alternative encoding.
>     >
>     >
>     >
>     >
>     > Please note that it may take a couple of minutes from the time of submission
>     > until the htmlized version and diff are available at tools.ietf.org.
>     >
>     > The IETF Secretariat
>
>
>     --
>     Cenk Gündoğan
>
>     Hamburg University of Applied Sciences
>     Dept. of Computer Science / Internet Technologies Group
>     Berliner Tor 7, 20099 Hamburg, Germany
>     Fon: +49 40 42875 - 8426
>     Mail: cenk.guendogan@haw-hamburg.de
>     Web: https://www.inet.haw-hamburg.de/
>
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg