IETF Logo Mail Archive

Re: [icnrg] Directions on CCNx TimeTLVs: draft-gundogan-icnrg-ccnx-timetlv

"Mosko, Marc <mmosko@parc.com>" <mmosko@parc.com> Wed, 20 November 2019 06:25 UTC

Return-Path: <mmosko@parc.com>
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 0360412004C for <icnrg@ietfa.amsl.com>; Tue, 19 Nov 2019 22:25:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=parc.onmicrosoft.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 kYLRRz7_-nbI for <icnrg@ietfa.amsl.com>; Tue, 19 Nov 2019 22:25:49 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750048.outbound.protection.outlook.com [40.107.75.48]) (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 56B36120125 for <icnrg@irtf.org>; Tue, 19 Nov 2019 22:25:49 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LMdcq0Pswrvee0cOgsjmlHf1zyhBH7IjvicfyXFIxhB/bfg1bubfh7taHFgcVCOPBPpEMrZBx07+ss//WhkMP1m/llcO1FsB7GJ8Z2Xfbbn65nLc3TBOHtNsFCHBxbeMUWzFU64/cbpozEfqF2rQjzUHVebQON/kz29Sdvz6NG9sZ6ebwlWqunUNpMIxHDETp8dF6tyhjyrBGlgwxi4bl0D9Ishd2Fuhtwa573fcaBJ4+MbpJqPsqqTLSON9y0Ae3Zsua6plfnoJHwNSExC62zwMSqM+oqpxj7L0rElA5srn7SqmL0Vf1zYCWyF82UCSEtPiCcqRWsPnO71M7sLn8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U+jys5uX2Xb9zimrSkMcFdga4ULQPU1FE62LYWdzFUo=; b=VvKvsIiG9n6sNwb06Ztr0AUj7803K3bThPi4e1K1FB+Xh0c/agNdD4UHQDmPwg4Iq1wlddu1b72uZt3Fd492axVdd67wf87T+kOu3rOtDu/YqzFsNQRdJaRTazs/R5fXAO2kbKdT5T/dwvMswNTL8EQT2eL9xgvJ7jr37QzTDLvfXmUz5ic0zWCHM1ArdmjjlVi1yAv3fuvNmZdlZppwvKVGaQHgdCAk52XbCtLyJY+rhDYbTBme3hiFCt4QsM+Fgs2NbWT7rjVL7AOXHFjl6Tsr4S93+fOeJ+MyUg2j0eiYdGc35Rtf+4gFxazYdmY3FNBrLuK1MZWucS4fthWh0g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=parc.com; dmarc=pass action=none header.from=parc.com; dkim=pass header.d=parc.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parc.onmicrosoft.com; s=selector2-parc-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U+jys5uX2Xb9zimrSkMcFdga4ULQPU1FE62LYWdzFUo=; b=eP+buBJmcZfKDI3m+uSbYQJpKGMljySXsmVuicsll1D6BiBS9hweLsC6pQhj7YoLZaBJvO7FTwwLkazqho3wMUAtwXrcBcZQVApwW70OHAtEF/j7tnZCUpEHM5FRPFUeWw+N9zvDeVI0IF2aHomotya71MSEzsGCei1KKgryu2o=
Received: from BYAPR15MB3272.namprd15.prod.outlook.com (20.179.59.145) by BYAPR15MB3237.namprd15.prod.outlook.com (20.179.59.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.28; Wed, 20 Nov 2019 06:25:45 +0000
Received: from BYAPR15MB3272.namprd15.prod.outlook.com ([fe80::78f2:5685:5bc3:3e27]) by BYAPR15MB3272.namprd15.prod.outlook.com ([fe80::78f2:5685:5bc3:3e27%6]) with mapi id 15.20.2451.031; Wed, 20 Nov 2019 06:25:45 +0000
From: "Mosko, Marc <mmosko@parc.com>" <mmosko@parc.com>
To: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>, "icnrg@irtf.org" <icnrg@irtf.org>
Thread-Topic: [icnrg] Directions on CCNx TimeTLVs: draft-gundogan-icnrg-ccnx-timetlv
Thread-Index: AQHVn1ipW2xJXkUxYkyIhm3+LbJMcKeTEd8A
Date: Wed, 20 Nov 2019 06:25:45 +0000
Message-ID: <9AB2EAD4-4458-4BD3-B263-A8C9BDAAB25B@parc.com>
References: <73a5a9ff-03c2-3b63-576d-8811c84b90c4@haw-hamburg.de>
In-Reply-To: <73a5a9ff-03c2-3b63-576d-8811c84b90c4@haw-hamburg.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1f.0.191110
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mmosko@parc.com;
x-originating-ip: [50.0.67.90]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cff3b85d-8e85-4cbe-0687-08d76d827a17
x-ms-traffictypediagnostic: BYAPR15MB3237:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR15MB3237105084E6FFE1CBB1580EAD4F0@BYAPR15MB3237.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02272225C5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(376002)(346002)(39840400004)(136003)(189003)(199004)(6436002)(11346002)(2616005)(256004)(486006)(81166006)(6246003)(305945005)(3450700001)(81156014)(66446008)(14444005)(102836004)(66476007)(66556008)(64756008)(9686003)(6512007)(6306002)(446003)(110136005)(58126008)(26005)(186003)(7736002)(76116006)(66574012)(316002)(76176011)(8676002)(476003)(36542004)(8936002)(86362001)(2501003)(71200400001)(2906002)(71190400001)(66946007)(66066001)(6486002)(19273905006)(6116002)(36756003)(3846002)(14454004)(33656002)(5660300002)(229853002)(478600001)(99286004)(25786009)(966005)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR15MB3237; H:BYAPR15MB3272.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: parc.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rxSWOirnKtq380R94t1LCUx3ifaTekogHsLQ9XXgK1nQDyvni6kl9kXtWuorh6FDiX53z/5z2t0ci3XBaOotZ6EE846tGkIjtgfET9FbTglB59JAXyhn9ZswIjqariXLIAPrs0w0hLtcFi/Gj8FN5bpU9qLhSA/30SfC0krHJAtgQzmwHM74Z8rlLoW1sL64PE7hoXuYt3Es9ZnChDZdXxqpBuheCweKFCNxCpAJ0MUgZ+MQOcROPnMI0I12ZDUt0FFkAN5CWxRMh1WX8QEx+VkYXd+jxj039xMQ5BYwGKAfx//Xj7uW6zzoXCm9j5UD8WZQuOa7Muy+EZMkEWwz3Xno/G0Xu4RxvV3NDHVG5WZIlnecsQYl2S0fnbedYuTovCDP4bvMsL4KSsC07JkOfBAgWpfYtvzrVDu7dmRI3q9wSYgZ/SaWqrZZ4wtFI95KR1YqfTQ8FBgfbCD1QD1+qP1yaX7yTHqn2Jef7cqyCbo=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <2BB9CA20F9619D44BCC61B1638C811E7@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: parc.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cff3b85d-8e85-4cbe-0687-08d76d827a17
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 06:25:45.6430 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 733d6903-c9f1-4a0f-b05b-d75eddb52d0d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +FT/1zkcEZ0MSvh5po9f9Ty8AdjXnoWJS/5BR8mjZQpVBjRk8BEnEjt8NpIVVmCE
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3237
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/JM-mhz_irmvHTwhtR-IsRTAR8u8>
Subject: Re: [icnrg] Directions on CCNx TimeTLVs: draft-gundogan-icnrg-ccnx-timetlv
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, 20 Nov 2019 06:25:52 -0000

Thomas,

I think having more compact encodings is great!  Here's a few comments on draft-gundogan-icnrg-ccnx-timetlv-00.

1) The caption of Fig 3 cites RFC 4574.  Is that correct?  It's also not in the references section.

2) RFC 5497 is not definitive in the representation of 1 or 2 byte floats, as C must be specified.  In your draft, it would be good to have a section that completely spells out how to go from a timestamp to/from mini/half floats.

3) I agree that playing with the signature time might have unintended security consequences.  The signature time might also be unrelated to other time fields in the packet as it might be generated independently of the content itself, so using it as a time base is not a good idea either.

4) If the RCT becomes relative, then a cache should decrement it.  I'm not a big fan for using relative times here, but it could be done.  I had written up an idea on allowing relative times as an alternative to absolute times in https://tools.ietf.org/html/draft-mosko-icnrg-cachecontrol-00.

5) I think fractions of a second are not important for fields like interest lifetime or RCT, so the exponent does not need to support negatives.  Removing a sign bit and keeping the exponent positive with a normalized form mantissa would have a fairly large range, at least for the 8-bit (a 0.4.4.-0 minifloat).  The 16-bit should keep all the bells and whistles as it has space, and you'd likely use IEEE half precision floats anyway?

Marc


On 11/19/19, 8:12 PM, "icnrg on behalf of Thomas C. Schmidt" <icnrg-bounces@irtf.org on behalf of t.schmidt@haw-hamburg.de> wrote:

    Folks,
    
    following up on our presentation of draft-gundogan-icnrg-ccnx-timetlv:
    
    This proposes to replace time deltas in CCNx by logarithmic encodings 
    and (maybe) some absolute timer values by deltas w.r.t. the signature time.
    
    We solicit feedback: Do you agree on going this way, or do you suspect 
    this to be harmful?
    
    Best,
      Thomas
    -- 
    
    Prof. Dr. Thomas C. Schmidt
    ° Hamburg University of Applied Sciences                  Berliner Tor 7 °
    ° Dept. Informatik, Internet Technologies Group   20099 Hamburg, Germany °
    ° http://inet.haw-hamburg.de/members/schmidt      Fon: +49-40-42875-8452 °
    
    _______________________________________________
    icnrg mailing list
    icnrg@irtf.org
    https://www.irtf.org/mailman/listinfo/icnrg

v2.23.0 | Report a Bug | By Email