Re: [icnrg] icnrg Digest, Vol 120, Issue 13

Cenk Gündoğan <mail+ietf@gundogan.net> Wed, 30 March 2022 06:49 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 CCBB13A0A50 for <icnrg@ietfa.amsl.com>; Tue, 29 Mar 2022 23:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.709
X-Spam-Level:
X-Spam-Status: No, score=-1.709 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 Isw7iJErAjxP for <icnrg@ietfa.amsl.com>; Tue, 29 Mar 2022 23:49:07 -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 C75B73A0A21 for <icnrg@irtf.org>; Tue, 29 Mar 2022 23:49:06 -0700 (PDT)
Received: from localhost (95.81.27.18.dynamic-pppoe.dt.ipv4.wtnet.de [95.81.27.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mail.localdomain (Postfix) with ESMTPSA id AC05648D3F; Wed, 30 Mar 2022 08:49:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gundogan.net; s=201712; t=1648622944; bh=2hQd/TD6wSbyEhboOJDyNhuHII5dbFRIr8/cRIWnuHg=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=lu4iLQWMzeH4rgy6GltVrv9eK85gt6IxM8WHlZl5pcexdma0Mv9V6Snj2LaxXdgF7 vE38rIUnJU9vfcveA8bD16zIco1sE4TlLk3LWYS0Kn11hwKeFSMlIneKhhc/3T7i7/ i5QoankBJhvPI+UywRwfFFuezraShKxizTEHzm0LhkUgFRK3jGNtp00q6qo/8UHm29 zajVK3iP8cacMU/aGdhiM13QNuonsDF7LLC8UdtcUbdZPtwM5zgKLblLPk7JH7BYaG 8NQzxh2A/cPW4EKxDXEeH6uq/xWFDloVBe7ilTcluQuRjhqpR0OB/727GTSRKAXgJQ txcAzMRBhz2/w==
References: <mailman.114.1648580550.29398.icnrg@irtf.org> <20B85BB3-12AA-45BD-AE0E-35E3356FA100@netlab.uky.edu>
User-agent: mu4e 1.6.10; emacs 29.0.50
From: Cenk Gündoğan <mail+ietf@gundogan.net>
To: Ken Calvert <calvert=40netlab.uky.edu@dmarc.ietf.org>
Cc: icnrg@irtf.org
Date: Wed, 30 Mar 2022 08:48:04 +0200
In-reply-to: <20B85BB3-12AA-45BD-AE0E-35E3356FA100@netlab.uky.edu>
Message-ID: <87lewsdjfj.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/7Wpx7qbaze0bWNO7pifZTqHGhJo>
Subject: Re: [icnrg] icnrg Digest, Vol 120, Issue 13
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, 30 Mar 2022 06:49:12 -0000

Hello Ken,

thanks for your comments, my response follows below, inline:

On Tue, Mar 29 2022 at 17:00 -0400, Ken Calvert wrote:

> Re: ccnx-timetlv:  I read the draft, and I saw Cenk's presentation.
> Adopting this seems fine.
>
> A couple of minor questions/comments:
>
> Motivation: If I understand correctly, this will reduce the size of TLVs where it is used from 12 to 5 total bytes, is that correct?

that's correct for the RecommendedCacheTime.  Turning absolute Unix
epoch time (T (2) + L (2) + V (8) ) to relative time using the compact
encoding T (2) + L (2) + V (1).

For the InterestLifetime the reduction varies, since that particular TLV
is of flexible length.  Larger lifetimes (minutes, hours) require >= 3
bytes with the "normal" encoding (which encodes millliseconds).  Here
also the compact encoding reduces that from >=7 down to 5.

>
> 5. Protocol Integration - I believe RFC 8609 specifies how an unknown
> type field should be handled (ignored/skipped over).  Does it also
> specify how an unexpected length field should be handled?  In the
> comparison of the alternative approaches, it might be good to describe
> what should happen when a packet using the compact encoding arrives at
> a legacy forwarder for each approach.  If RFC 8609 does not specify
> what to do if a length is different than expected, perhaps that should
> be included with the changes.  One wonders if the parser might decide
> it has lost sync and throw the whole packet away...
>

Good point.  At a quick glance, I found this statement [1]:

10.3.9.  Malformed Interest

   If a forwarder detects a structural or syntactical error in an
   Interest, it SHOULD drop the Interest and MAY send an Interest Return
   to the previous hop.  This does not imply that any router must
   validate the entire structure of an Interest.

[1] https://datatracker.ietf.org/doc/html/rfc8569#section-10.3.9

I couldn't find any other references, so I think its useful to add more
details on the behavior of legacy forwarders for the different
approaches.  Thanks!

Cheers,
Cenk

> Ken
>
>
>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg