This document proposes using an interest digest indexed PIT table to improve lookup performance in NFD. It implements interest digest hashing in ndn-cxx and NFD. Benchmark tests show minor performance gains, reducing average RTT by up to 1.39ms with 4 name components. However, the authors conclude the interest digest proposal does not provide enough benefits to change NFD forwarding semantics given debates around its security impacts.

1. Initial Implementation of
Interest Digest in NFD
Junxiao Shi, Lei Pi, Qi Zhao, Chengyu Fan
20170326

2. Current name-based PIT lookup
• PIT is indexed by Interest name.
• When Data arrives, NFD performs a longest prefix
match on the PIT using the Data name, then
continues to find additional PIT entries that can be
satisfied by the Data.
• Example:
• PIT has entries /A/B and /A/B/C.
• Data /A/B/C/D arrives.
• LPM finds /A/B/C.
• /A/B is also satisfied by this Data.

3. Interest digest proposal
• PIT is indexed by a digest of Name+Selectors+Link.
• This digest is attached to every Interest/Data/Nack
packet in hop-by-hop NDNLPv2 header.
• The header is not covered by Data signature.
• Data’s InterestDigest header means “I can satisfy the
pending Interest with digest X”.
• When Data arrives, the PIT entry it can satisfy is
quickly found with the digest.
• Every Data can satisfy only one PIT entry.

4. Let’s put the arguments aside
• There have been debates about:
• SHA1 vs SHA256
• “Data satisfying only Interest” is bad
• Is the Interest digest required?
• Can we mitigate cache poisoning attacks by this?
• The goal of our project is to quantity the maximum
potential performance benefit.
• We use SHA1.
• We require InterestDigest header on every packet.
• We focus on performance, not security.

5. Implementation in ndn-cxx
• NDNLPv2 InterestDigest header
• Consumer API Face::expressInterest
• compute Interest digest and add the header
• Producer API Face::put
• add InterestDigest header onto Data/Nack packets

6. Implementation in NFD
• Move PIT off NameTree
• Implication: FIB/StrategyChoice lookup given a PIT entry
requires a name-based lookup, instead of following
pointers on the NameTree entry
• Index PIT with InterestDigest instead of name
• Simplify incoming Data pipeline
• because Data can satisfy at most one PIT entry
• Save weak_ptr<Strategy> in PIT entry
• avoid NameTree lookup for StrategyChoice on data path

7. Benchmark method
• Open Network Laboratory (ONL)
• 16 consumer-producer pairs communicate through
one bottleneck router
• ndnping, 1000 Interests/s/consumer
• 4 or 11 NameComponents

8. Benchmark result
router CPU usage average RTT
baseline, 4-component 93-96% 3.83ms
digest, 4-component 91-94% 2.44ms
baseline, 11-component 95-98% 13.19ms
digest, 11-component 95-97% 13.12ms

9. Conclusion
• Interest digest offers minor performance gain.
• However, until additional benefits are proven (such
as cache poisoning mitigation), it is not worthwhile
to change forwarding semantics for this minor
performance gain.
• Our future work includes additional profiling to
understand whether NameTree continues to be a
bottleneck in forwarding pipelines.