[ndnSIM] [Nfd-dev] Interest Satisfaction Rate (ISR) Calculation
shijunxiao at email.arizona.edu
Tue Apr 3 08:43:40 PDT 2018
Thanks for your quick response. It is very valuable.
I agree that not incrementing either counter makes sense.
> > I have a related question: what does "Interest satisfaction rate" for
> > a
> > nexthop means on a forwarder?
> > Consider the scenario where a forwarder G has one downstream node C,
> > and
> > two upstream nodes (aka nexthops) P and Q:
> > /---P
> > C---G
> > \---Q
> > G is using multicast strategy.
> > When it receives an Interest from C and forwards it to both P and Q, P
> > responds immediately and the Data goes back to C.
> > As in a recent NFD commit
> > <
> > (which will appear in ndnSIM sooner or later), there isn't a
> > "straggler
> > timer" anymore so the PIT entry is removed immediately.
> > Q responds several milliseconds later, at which time the PIT entry at
> > G is
> > already gone and G drops the Data.
> > Should G count a "Interest satisfaction" on nexthop Q, or count a
> > "Interest
> > timeout" on nexthop Q, or neither?
> Well, you clearly can’t just increment the interest satisfaction
> counter, since that would allow a compromised upstream forwarder to blast
> unrequested data packets in order to divert traffic onto its path.
> Conversely (although not quite as bad), counting as an interest timeout
> would penalize an upstream forwarder who in fact just responded second
> (which could be due to something as simple as a slightly longer RTT.)
> Doing neither seems the right compromise if one removes PIT state on
> satisfaction rather than just marking the PIT satisfied and cleaning it
> up in a lazy fashion. Unless you’re under memory pressure, leaving the
> satisfied PIT around until the Interest expiration timer goes off is
> likely to be a much better approach overall and renders this question
NFD used to have "straggler timer" and keep the PIT entry for 100ms longer,
although it never had the Interest satisfaction rate metric.
In practice, keeping the PIT entry causes lots of engineering complexity:
* It needs a timer to clean up, which increases the overhead on the global
* If the CS entry is evicted, forwarding has to distinguish whether the PIT
entry is active so it aggregates the Interest, or the PIT entry is waiting
for deletion so it reactivates the PIT entry and sends the Interest.
* I cannot apply the technique in *Named data networking on a router: Fast
and DoS-resistant forwarding with hash tables* and use the same hash table
entry for PIT entry and CS entry, when they happen to have an exact name.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ndnSIM