Subject: [icnrg] CCNx 1.0 Interest for a "stale" content object

From: "Thompson, Jeff" <[email-masked]>
Date: Mon, 21 Sep 2015 16:02:15 +0000

Hello Marc (or other CCNx folks),

A CCNx 0.8 Interest had an AnswerOrginKind selector which allowed a STALE bit so that the forward could return a Content Object which has passed its expiry time (if available).

However, in CCNx 1.0, section 3.6.2.2.2 says "A cache or end system should not respond with a Content Object past its ExpiryTime."
https://www.ietf.org/id/draft-irtf-icnrg-ccnxmessages-00.txt

So, this Interest selector is dropped and a CCNX 1.0 forwarder does not return "stale" data. Is that right?

Thanks,
- Jeff T

---

From: <[email-masked]>
Date: Mon, 21 Sep 2015 17:30:40 +0000

Jeff,

What you said is almost correct, but does not cover the whole issue.  Here’s my explanation.

Expiry time is the final death of a Content Object, as far as the Content Store or a producer is concerned.  It can still be forwarded along the fast path, if it was already in flight when it expired.  [1]

The Recommended Cache Time (RCT) is the time until which the object is ‘fresh’ and after which it is ‘stale’, if you want to use those terms.  The Expiry Time takes precedence over the RCT.  The RCT is the producer’s estimate of the time until which the object is popular or fresh enough to consider caching.

There is no “answer origin kind” equivalent.  I think we’ve talked about this before, but I’ll reiterate my opinion on this: it is not safe.  In the CCNx 0.x and NDN world with Freshness as a relative time in a Data message, there is no way for a consumer to know if a Data message is in answer to a ‘stale allowed’ or ‘stale disallowed’ message.  This is best explained with an example.  Nodes A - B - C - D - E form a network.  node D has a stale copy of the Data and node E can produce a fresh copy.  B sends an Interest #1 for ‘stale disallowed’ to C.  Node A sends an Interest #2 with ‘stalk OK’ to B.  The Interest does not match the first interest so B forwards it to C.  Interest #1 must go to node E, Interest #2 only goes to node D.  D returns a stale Data object to C who returns it to B.  How does B know if the Data object answered the ‘stale ok’ or ‘stale disallowed’ Interest?  Node B has no way of deciding this.  Further, the ‘fresh’ copy from node E would be dropped at node D because there is no PIT entry left (I’m assuming an adversarial timing of events).

The the ExpiryTime and RCT in CCNx 1.0, because they are absolute times, one can always tell if it is past the RCT or past the ExpiryTime.  But we don’t have a way of asking for ‘must be within the RCT’ anyway, so that is a bit moot.

[1] It may be that there’s some archival system that lets one fetch historical objects, but that is not the normal role of a producer or content store and may require encapsulation — we’ve not specified anything about that.

Marc

On Sep 21, 2015, at 6:02 PM, Thompson, Jeff <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
- Jeff T
_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg