際際滷

際際滷Share a Scribd company logo

NFD InterestDigest

Download as PPTX, PDF
Shi Junxiao
Shi Junxiao

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 of 9
Download to read offline
Initial Implementation of Interest Digest in NFD Junxiao Shi, Lei Pi, Qi Zhao, Chengyu Fan 20170326
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.
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. Datas 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.
Lets 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.
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
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
Benchmark method Open Network Laboratory (ONL) 16 consumer-producer pairs communicate through one bottleneck router ndnping, 1000 Interests/s/consumer 4 or 11 NameComponents
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
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.

More Related Content

NFD InterestDigest

  • 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. Datas 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. Lets 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.