[Nfd-dev] Interest lifetime limit

[Burke, Jeff]

Hi,

I agree with Alex - I am not suggesting either infinite lifetimes or hard state.

What I am suggesting is:

1) We don't know enough to set a practical bound on interest lifetime, so let's leave the bound set to  limit of the data type used for storing it (or one less than that), until we have some operational experience with what a reasonable value would be.     If it is to be operator-configurable anyway, this could be set in a configuration file that is easy to modify in future distributions or for particular installations.

2) Reserve the maximum int/long value to correspond to "as long as the forwarder is willing to hang on to the interest" - this is not infinite lifetime but does leave the possibility for long-lived interest support in certain deployments, or with deployment-specific PIT cleanup strategies.

I realize there is a practical concern but this seems related to the current state of the implementation - If the worry with these is related to not yet having a PIT cleanup mechanism, I would suggest that this is a basic feature that should be incorporated into the initial NFD release.  (Same with content store and FIB limits / cleanup.)   Even at this stage, busted or intentionally aggressive apps should not be able to crash the forwarder by filling these tables - this could happen even with relatively low maximum lifetimes.  Cleanup info also needs to be logged and someday available through the instrumentation mechanisms;  this has already come up in Peter's debugging of ccnx–caused delays in ndnrtc packet flows.

Thanks,
Jeff


From: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Date: Fri, 21 Mar 2014 09:57:56 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>, Giovanni Pau <gpau at cs.ucla.edu<mailto:gpau at cs.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Interest lifetime limit

Hi all,

In my opinion, not having the limit and considering that one can set infinite interest lifetime is not entirely correct.  Isn't the whole point of the Interest/Data exchange is to provide flow balance? And when you separate Interest from Data by a significant portion of time, I don't see how it works out to the flow balance.

Interests are generally soft state.  The client issues Interest and expects data.  Within reasonable time interval, routers expect that the client is still down there and the network topology didn't change, so the response would reach.  When we are getting to "unlimited" lifetimes, we are going towards "hard" state on routers, without any guarantee that the client is still alive or that the network hasn't changed.

As I remember, Van was always saying that Interest should be a bilateral agreement between two neighbors.  If downstream is still interested, it should re-express its interests.  This by definition assumes finite lifetimes (either global maximum or neighbors explicitly communicate their maximum).

In any case. The main reason I asked this question is that I have a desire to provide a basic protection against abuse of the NDN routers, at least in the testbed environment.  If we don't do it in a reasonable way, anybody can send a bunch of interests with huge lifetimes and then just go home, while network will suffer until it is rebooted (or we have a reasonable mechanism PIT cleanup implemented).

---
Alex


On Mar 21, 2014, at 7:29 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:


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.
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140322/d0060f8c/attachment.html>