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

From: Ken Calvert <[email-masked]>
Date: Tue, 29 Mar 2022 17:00:52 -0400

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?

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...

Ken

---

From: Cenk Gündoğan <[email-masked]>
Date: Wed, 30 Mar 2022 08:48:04 +0200

Hello Ken,

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

> 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
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg