[Nfd-dev] Interest lifetime limit

Giovanni Pau gpau at cs.ucla.edu
Sun Mar 23 17:54:32 PDT 2014 

On Mar 23, 2014, at 12:50 PM, Lixia Zhang <lixia at cs.ucla.edu> wrote:

> Below is a quick summary of the NFD chat this morning (Beichuan, Junxiao, Steve, Alex, me), hopefully it addresses Christos comments below.  
> 
> 1/ What's implemented in release-1 (the email exchanges showed some misunderstandings about this)
> - Each Interest carries a lifetime
> - One can control the upper bound of this lifetime
>  through configuration.
> - This magic number Junxiao threw out, 2^15 msec, is meant to be
>  the default max Interest lifetime, if no lifetime bound is
>  configured.
> 
> In short, release-1 does allow you to set any arbitrarily long Interest lifetime.

>>> It sounds good this will allow to understand what can happen with very long interests

> 
> 2/ Interest lifetime and soft-state
> Generally speaking, the desire of using arbitrarily long Interest lifetime does not seem to match the soft-state spirit of NDN.
> 
> If some application really wants "long-lived Interest", one can probably support that desire through some library function which can periodically re-send the long-lived Interest to refresh the network PIT state.

My only concern (and ignorance as we did not check the issue thoroughly yet) is that given a MAX_LIfetime for the interest  in our VNDN case we may result flooding the network, especially in dense cases such as Wilshire at 4.30 pm. 


> 
> 3/ We need to understand the consequence of purging Interests: PIT state (breadcrumb trace along the path between consumer and where the data is) must be consistent to get the Data back to the consumer. 
> If any individual node purges its PIT table entries, it destroys the breadcrumb trace and Data can't make back 
> (Alex told the story that some ndnSIM players had done this PIT entry purge game, and cried "how come I got so many Interests timeouts?" ;-)

I fully agree with 3. we need to understand the consequences of this, very deeply, once ICN deadline is over i may try to evaluate the effect of 1min or 5 min interest (that is the order i’m thinking) on very dense situations. 

> 
> 4/ The idea mentioned in 2/ (letting node refresh the Interests it wants to stay in PIT) also matches the scheme that Van talked a while back regarding the PIT size control: an upstream router should set an upper bound on the Interest lifetime received from a downstream router, saying "I'll keep all Interest you send to me no more than N seconds".  So it is up to the downstream router to retransmit those Interests that did not get satisfied in N seconds.
> 
> (One might think "what's the gain for purposely making downstream send the same Interests multiple times" -- that's my question before. Then I realized that this "retransmitting" gives the downstream router an opportunity to re-prioritize the Interests that it really wants to get)


Agree on 4, sounds reasonable though the optimal N may vary a lot. 

> 
> this may be the direction to consider for PIT size management instead of purging PIT entries, for wired Internet.  I will work with our vehicle group to figure out whats best for vehicle situation (there is no persistent trace/path/neighbor in that case).

Fully agree that the breadcumbs are not there as mobility change and in this case is hard to understand what will happen without due simulations. One consequence that comes to my mind is that for a while there may be node with the interest pending but no longer in the path towards the consumer.  

Waiting for you In Paris, will be a lot of Fun ;) !!!


> 
> Lixia
> 
> 
> On Mar 23, 2014, at 6:16 AM, Christos Papadopoulos <christos at cs.colostate.edu> wrote:
> 
>> Let me see if I can summarize (for my sake) and then ask a question:
>> 
>> - Alex wants a defense mechanism in the PIT to guard against resource exhaustion from too many pending Interests (great to have such a mechanism, BTW).
>> 
>> - Alex suggests a reasonably short Interest lifetime in the PIT.
>> 
>> - Note, however, that this does not guard against deliberate attacks (or even nasty bugs such a congestion control scheme gone awry) - one can always send a flood of interests to overflow a PIT with any reasonable Interest lifetime.
>> 
>> - As I see it, options are (a) set a short default as a first line defense and leave it at that for now, or (b) set a longer default but have a more sophisticated mechanism to purge PIT state when we hit the limit.
>> 
>> - Along with Jeff and Giovanni, I do like option (b) with an operator configurable default. I also like Jeff's suggestion to pick a point value to mean "as long as you can". Local policies always prevail, of course, and these interests might be the first to be purged in case of overload.
>> 
>> - I would like the default be the common case, which I think means the shorter value.
>> 
>> - So my question to Alex is, do you think it is feasible to have some resource exhaustion defense mechanism in this version of NFD beyond a short Interest lifetime, and being mindful of the implementation effort at this stage, what would you suggest?
>> 
>> Christos.
>> 
>> 
>> On 03/22/2014 07:52 PM, Alex Afanasyev wrote:
>>> This case seem to be slightly different that a general case with Interests.  I suspect, the intention is not send out Interests, but just keep PIT state locally alive, as long as the application alive.  (Am I missing something here and this state is beyond just local app-local daemon?)  For this case, I suspect, we can do something special.
>>> 
>>> --
>>> Alex
>>> 
>>> On Mar 22, 2014, at 6:48 PM, Giovanni Pau <gpau at cs.ucla.edu> wrote:
>>> 
>>>> 
>>>> In principle i agree for a default value of any time 32 sec are a bit short but if there is consensus is fine. In the vehicular case i would like to be able to issue an interest for something like /hazards/my-location/ahead of me/ and let it alive for at least several minutes, radio resources are scarce and renewing this every 30 sec appears to me a bit too much as you always want to know if there are hazards, or accidents..
>>>> 
>>>> That said, i agree for a reasonable default,
>>>> 
>>>> 
>>>> /g.
>>>> ==========================
>>>> It had long since come to my attention that people of accomplishment rarely sat back and let things happen to them. They went out and happened to things.
>>>> 
>>>> - Leonardo da Vinci
>>>> ==========================
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Mar 22, 2014, at 6:33 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
>>>> 
>>>>> I agree, but want to bring out the problem of soft state again.  Why would routers want to keep PIT state for a prolonged period of time if it has no idea if the downstream still has interest in the data.
>>>>> 
>>>>> As for (1).  Data type used for lifetime allows expressing time durations from 1 milliseconds to billion years and more (it is 2^64 milliseconds), so it is really not a "practical" bound.
>>>>> 
>>>>> ---
>>>>> Alex
>>>>> 
>>>>> On Mar 22, 2014, at 6:25 PM, Giovanni Pau <gpau at cs.ucla.edu> wrote:
>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> I agree in full with Jeff arguments below that actually summarize my points even better than what i did myself. At this moment we know to little and bounding ourselves is not a good idea. Also in some environment may be smart to have relatively long time interest and have a smart  Pit cleanup strategy.
>>>>>> 
>>>>>> thanks
>>>>>> Giovanni.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Mar 22, 2014, at 10:47 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> 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>
>>>>>>> Date: Fri, 21 Mar 2014 09:57:56 -0700
>>>>>>> To: Jeff Burke <jburke at remap.ucla.edu>
>>>>>>> Cc: Junxiao Shi <shijunxiao at email.arizona.edu>, Giovanni Pau <gpau at cs.ucla.edu>, "nfd-dev at lists.cs.ucla.edu" <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> 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>
>>>>>>>> Date: Thu, 20 Mar 2014 22:17:37 -0700
>>>>>>>> To: Giovanni Pau <gpau at cs.ucla.edu>
>>>>>>>> Cc: Jeff Burke <jburke at remap.ucla.edu>, <nfd-dev at lists.cs.ucla.edu>, Lixia Zhang <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> 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
>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

More information about the Nfd-dev mailing list