[Nfd-dev] Interest lifetime limit

[Burke, Jeff]

If it is going to be operator configurable, perhaps we can leave the practical limit set to the theoretical limit for research versions of NFD?  I don't think we have enough experience with the tradeoffs you describe to pick an upper bound at this time.

In my understanding, there is no real cost to the forwarder for long-lifetime interests, because it will need a mechanism to drop old pending interests when the PIT is full anyway.   Unless forwarder PIT behavior is controlled in some special way by specific operators on behalf of local applications (as it might be in Giovanni's vehicular apps),  the burden is always on the application to refresh the interest with an update period that is no longer than the maximum tolerable delay for a response to the Interest, because there are no guarantees on what stays in the PIT.

Further, are we sure that long-lived interests might not be common in some applications?   For example, if an application checks for automatic 'software updates' by issuing an interest every hour, what does that application have to lose by setting the Interest lifetime to one hour, even if it is not guaranteed to persist?

Jeff

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Thu, 20 Mar 2014 22:17:37 -0700
To: Giovanni Pau <gpau at cs.ucla.edu<mailto:gpau at cs.ucla.edu>>
Cc: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>, <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>, Lixia Zhang <lixia at cs.ucla.edu<mailto:lixia at cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest lifetime limit


20140114 meeting discussed InterestLifetime upper bound. Van's idea is:

* Protocol should not set an upper bound on InterestLifetime.
* Setting a *practical* upper bound is a policy issue, configurable by operator.

My proposal of using 32768ms as the default upper bound is completely unrelated to "2 octets". Its reason is:

* Most applications don't need any special lifetime.
* NFD Notification mechanism is more efficient if longer lifetime can be used. Push applications also desire a long lifetime.
* Forwarder cannot afford long lifetime because PIT entries consume memory.
* Trade-off between the need of push application and the forwarder state cost leads to 32768ms default upper bound.

Yours, Junxiao

On Mar 20, 2014 9:52 PM, "Giovanni Pau" <gpau at cs.ucla.edu<mailto:gpau at cs.ucla.edu>> wrote:
>
> Junxiao,
>
> sorry i can’t get it, if we have 64bits, then why we need to bound it to a 16bit value? I agree is better to measure in ms rather than sec, but yet i do not understand the need to bound. I agree with jeff on the long timed interests, in our case such as an interest for a road-hazard in the direction of traveling.
>
> Thanks
> g.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140321/e89f1ded/attachment.html>