<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div><br>
</div>
<div>Hi,</div>
<div><br>
</div>
<div>I agree with Alex - I am not suggesting either infinite lifetimes or hard state. </div>
<div><br>
</div>
<div>What I am suggesting is:</div>
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>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. </div>
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>Thanks,</div>
<div>Jeff</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Alex Afanasyev <<a href="mailto:alexander.afanasyev@ucla.edu">alexander.afanasyev@ucla.edu</a>><br>
<span style="font-weight:bold">Date: </span>Fri, 21 Mar 2014 09:57:56 -0700<br>
<span style="font-weight:bold">To: </span>Jeff Burke <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>><br>
<span style="font-weight:bold">Cc: </span>Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>>, Giovanni Pau <<a href="mailto:gpau@cs.ucla.edu">gpau@cs.ucla.edu</a>>, "<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>"
<<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Nfd-dev] Interest lifetime limit<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>Hi all,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>---</div>
<div>Alex</div>
<div><br>
</div>
<br>
<div>
<div>On Mar 21, 2014, at 7:29 AM, Burke, Jeff <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;">
<div><br>
</div>
<div>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.
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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? </div>
<div><br>
</div>
<div>Jeff</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);">
<span style="font-weight:bold">From: </span>Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>><br>
<span style="font-weight:bold">Date: </span>Thu, 20 Mar 2014 22:17:37 -0700<br>
<span style="font-weight:bold">To: </span>Giovanni Pau <<a href="mailto:gpau@cs.ucla.edu">gpau@cs.ucla.edu</a>><br>
<span style="font-weight:bold">Cc: </span>Jeff Burke <<a href="mailto:jburke@remap.ucla.edu">jburke@remap.ucla.edu</a>>, <<a href="mailto:nfd-dev@lists.cs.ucla.edu">nfd-dev@lists.cs.ucla.edu</a>>, Lixia Zhang <<a href="mailto:lixia@cs.ucla.edu">lixia@cs.ucla.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Nfd-dev] Interest lifetime limit<br>
</div>
<div><br>
</div>
<div dir="ltr">20140114 meeting discussed InterestLifetime upper bound. Van's idea is:</div>
<div dir="ltr">* Protocol should not set an upper bound on InterestLifetime.<br>
* Setting a *practical* upper bound is a policy issue, configurable by operator.<br>
</div>
<div dir="ltr">My proposal of using 32768ms as the default upper bound is completely unrelated to "2 octets". Its reason is:</div>
<div dir="ltr">* Most applications don't need any special lifetime.<br>
* NFD Notification mechanism is more efficient if longer lifetime can be used. Push applications also desire a long lifetime.<br>
* Forwarder cannot afford long lifetime because PIT entries consume memory.<br>
* Trade-off between the need of push application and the forwarder state cost leads to 32768ms default upper bound.</div>
<div dir="ltr">Yours, Junxiao</div>
<div dir="ltr">On Mar 20, 2014 9:52 PM, "Giovanni Pau" <<a href="mailto:gpau@cs.ucla.edu">gpau@cs.ucla.edu</a>> wrote:<br>
><br>
> Junxiao,<br>
><br>
> 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.<br>
><br>
> Thanks<br>
> g.</div>
</span></div>
_______________________________________________<br>
Nfd-dev mailing list<br>
<a href="mailto:Nfd-dev@lists.cs.ucla.edu">Nfd-dev@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</span>
</body>
</html>