1. Name-based Packet Forwarding
Analysis and Improvement of
Name-based Packet Forwarding
over Flat ID Network Architectures
António Rodrigues1,2,3
Peter Steenkiste1
Ana Aguiar2,3
Carnegie Mellon University, PA, USA1
University of Porto, Portugal2
Instituto de Telecomunicações, Portugal3

2. Outline Hierarchical names, flat IDs and aggregation
Packet Forwarding with Bloom Filters
Impact of False Positive matches in Bloom Filters
Evaluation in Realistic Topologies
Conclusions
in this work, we look at an packet forwarding method for ICNs which uses Bloom Filters as content identifiers
more specifically, we analyze the impact of fp matches on the forwarding correctness of the method
- i'll start with a motivation for the use of bfs
- i'll explain how the packet forwarding method works
- i'll then dive into the analysis of the impact of fps
- and then conclude

3. Packet forwarding in ICNs: Names vs. Flat* IDs
Hierarchical names
Flat IDs

4. Packet forwarding in ICNs: Names vs. Flat* IDs
Hierarchical names
Flat IDs
Variable size content labels
✔︎ Fixed-sized content labels
✔︎ Aggregation → FIB scalability
✘ No aggregation → no FIB scalability
✔︎ No need for name lookups
✘ Needs a name-to-ID lookup service
prefix
next hop
/acme R2 ID
next hop
012b337 R2
ac864c7
be4678c R3
Name ID
/acme/A/101
012b337
/acme/A/3
ac864c7
id of ‘/acme/A/101’? R1 R2 C1 S2
get(/acme/A/101) or get(012b337)
Name ID
/acme/B/101
be4678c R4

5. Packet forwarding in ICNs: Names vs. Flat* IDs
Hierarchical names
Flat IDs
Can we bring the advantages of hierarchical names to flat ID architectures?

6. Outline Hierarchical names, flat IDs and aggregation
Packet Forwarding with Bloom Filters [1]
Name encoding
Lookups
Routing & aggregation
Impact of False Positive matches in Bloom Filters
Evaluation in Realistic Topologies
Conclusions
[1] : Papalini et al., Scalable Routing for Tag-based Information-Centric Networking. In ICN '14

7. Bloom Filters : Name Encoding
Hierarchical name encoding into Bloom Filters
✔︎ Fixed-sized content labels
‘/a/b/c’
3 sub-prefixes in ‘/a/b/c’
✔︎ No name lookups
hash(/a/)
hash(/a/b)
hash(/a/b/c) ? 1 1 1
Size of Request ID (RID) is the # of encoded sub-prefixes, or |R| = 3

8. Bloom Filters : Lookups
Lookups on FIB : Longest Prefix Matching (on names) using Bloom Filters
RID in request packet
✔︎ Simple forwarding semantics 1 ✘
✔︎ Longest-prefix matching
RIDs in FIB
|F|
iface
rid(/a/b)=
TP match 1 1 1 1 1 1 2 A ✔︎
No match
rid(/a/z)= 1 1 1 1 1 1 2 C ✘

9. Bloom Filters : Routing & aggregation
Routing & prefix aggregation
Name
|F|
next
cost
/a/c 2 R5 /a 1
/a/d R3 3
/a/b R2 R1 R2 /a
/a/b 1 /a 1
/a/b R5 R6 1
Aggregation 1
/a/c 3
Shortest path
RID
|F|
next
cost
rid(/a) 1 R5
rid(/a/b) 2 R2 R4
/a/d R3
/a/c
/a/d /x
prefix announcement 1
link cost
✔︎ Prefix aggregation R4
router
cache

10. Outline Hierarchical names, flat IDs and aggregation
Packet Forwarding with Bloom Filters
Impact of False Positive matches in Bloom Filters
What is a False Positive match?
Router-level impact
Network-level impact
Evaluation in Realistic Topologies
Conclusions

11. The problem with Bloom Filters: False Positive Matches
rid(/x)=
RID in FIB
|F|
iface 1 D ✔︎
FP match
rid(/a/b/c)=

12. Router-level Impact of FPs
Forwarding outcomes Rx Rz /f Rw Ry
/a/c
/f/y/v
/a/y
/a/b /g ✔︎ Rx Rz /f Rw Ry
/a/c
/a/y/v
/a/y
/a/b /g ✔︎
Matched interfaces
FP vs TP match size
|FP|<|TP|
|FP|=|TP|
|FP|>|TP|
Different C1 C5 C6
Equal C2
Matched interfaces
FP vs TP match size
|FP|<|TP|
|FP|=|TP|
|FP|>|TP|
Different C1 C5 C6
Equal C2
How likely are forwarding errors C5 and C6?

13. Forwarding Errors in Practice
Parameter
Value(s)
BF size
192 bit
|R| 10
# of FIB entries
106
|F| distr.
Unif.([1,10])
# of requests
1000
|TP| distr.
C5:
C6:
~10s or FPs per request
~ 1 FP per every 2 requests
High # of FPs for max. levels of aggregation
What’s the impact of FP matches on a network level?

14. Network-level Impact of FPs
/a/b
|FP|>|TP| R1 R2 ✔︎ BF
|F|
next
bf(/a) 1 …
bf(/a/b) 2 /a
/a/b R5 R6 ✔︎ ✔︎ ✔︎ R4 R3 ✔︎
request
bf(/a/y/z)

15. Network-level Impact of FPs/b
|FP|=|TP| ✔︎ R1 R2 ✔︎ BF
|F|
next
bf(/a) 1 R5
bf(/b) R2 … /a /b ✔︎ R5 R6 ✔︎ ✔︎ ✔︎ ✔︎ ✔︎ R4 R3 ✔︎
request
bf(/a/y/z)
What is the impact of FP matches in realistic networks?

16. Outline Hierarchical names, flat IDs and aggregation
Packet Forwarding with Bloom Filters
Impact of False Positive matches in Bloom Filters
Evaluation of FP impact in Realistic Topologies
BF-based forwarding model
Evaluation setup & methodology
Results
Conclusions

17. BF-based Forwarding Model : Inputs
Input 1 : Topology
Input 2 : BF parameters 1 3 /a R1 R1 R2
/*/* 5
Scope
Parameter
Request
BF size (bit)
Requests size |R|
Router
|F| distr. for all {Rx, iface i}
# of FIB entries … 2 R5 R6 R4 R3 4
request

18. BF-based Forwarding Model : Outputs
P([R1 … R5])
Find every possible path for a request R4
P([R1 … R6])
Probability of each path R6
Avg. # of request outcomes and path latency :
Correct and incorrect request deliveries
Avg. latency measured in # of hops R3 R2 R1
Avg. # of match events, at every router :
Local match
Single matches
Multiple matches R1 1 2 3 R2 R3
request
Local match
Single matches
Multiple matches R1 1 2 3 R2 R3
request
Local match
Single matches
Multiple matches R1 1 2 3 R2 R3
request

19. Evaluation : Setup
Realistic topologies : PoP-level topologies from the Rocketfuel dataset [1]
Autonomous System
# Nodes
# Links
Node out-degree
Path lengths ID
ISP
Mean
Max.
1221
Telstra (AU) 44
2.0 18 3 6
3257
Tiscali (EU) 41 87
4.2 28
2.5 5
3356
Level3 (USA) 62
284
9.2 39 2 4
7018
AT&T (USA)
114
148
2.6 25
AT&T [1]
[1] : Spring et al., Measuring ISP topologies with Rocketfuel. In SIGCOMM '02

20. Evaluation : Methodology
for each topology:
create 20 <src, dst> node pairs (paths)
for each parameter combination
calculate average of model outputs over 20 <src, dst> pairs
for each node pair:
generate evaluation cases for the pair
eval_cases = [
{ <src, dst>, { bf-size : 192, table-size : 107, …} },
{ <src, dst>, { bf-size : 256, table-size : 107, …} }, … ]
for each evaluation case:
generate & collect model outputs (e.g., P(match events))
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)

21. Outline Hierarchical names, flat IDs and aggregation
Packet Forwarding with Bloom Filters
Impact of False Positive matches in Bloom Filters
Evaluation of FP impact in Realistic Topologies
Results:
Scenario 1 : Global reachability
Scenario 2 : CDN-style caching
Improvements to BF-based forwarding
Conclusions
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)

22. Scenario 1 : Global Reachability
Sources of requested content : 1 origin server
Path lengths : 4 hops (to origin)
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)
Content space : Each node
serves 1/N * 107 entries
Forwarding: Forward over all matching interfaces
Table size : 107 entries
Aggregation : all entries in FIBs :
size |F| = 1 (max. aggregation) or |F| = 5
Request size : |R| = 10

23. Global Reachability: Impact of BF & entry sizes
Avg. number of links used per request
|F|=1 (max. aggregation)
|F|=5
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)
Ideal
Ideal 4 4
Link usage excess as high as 1000x for short BF sizes
Forwarding errors less likely from 384 bit up

24. Scenario 2 : Pro-active Caching I
Content sources : 1 origin server
Path lengths : 4 hops
Cache size : Each node serves
1/N * 107 entries
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)
Caches added 2 hops from req. source
Caches announce entries of
sizes |F| = 4 and 5
Aggregation : all entries in FIBs : size |F| = 1 (max. aggregation)
Table size : 107 entries
Request size : |R| = 10

25. Scenario 2 : Pro-active Caching II
Varying number of caches around
req. source:
A single cache
50%
All
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)
Caches added 2 hops from req. source
Caches announce entries of
sizes |F| = 4 and 5

26. Pro-active Caching : Cache Miss
Avg. number of links used per request & % of corr. deliveries
A single cache
50%
All
% of nodes surrounding the req. source which are caches
% of correct deliveries
for a single cache case
for 50% caches case
for All
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)
100
: Ideal deliv. %
Forwarding errors are less likely due to low FP rates
Caches are always picked over origin
Ideal link usage 4

27. Pro-active Caching : Cache Hit
Avg. number of links used per request & % of corr. deliveries
A single cache
50%
All
% of nodes surrounding the req. source which are caches
% of correct deliveries
for a single cache case
for 50% caches case
for All
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)
Forwarding errors are less likely due to low FP rates
100
: Ideal deliv. %
With more choices, more forwarding errors
Only a single cache entry to choose from
Ideal link usage 2

28. Outline Hierarchical names, flat IDs and aggregation
Packet Forwarding with Bloom Filters
Impact of False Positive matches in Bloom Filters
Evaluation of FP impact in Realistic Topologies
Results:
Improvements to BF-based forwarding
Prefix exclusion
Fallbacks
Conclusions
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)

29. Improvement I : Prefix Exclusion
Idea : Reduce the number of sub-prefixes encoded in RIDs
/a/b/101
/a/b/102
/a/b/103
/a/b/104 …
|R| = 3 = |{‘/a’, ‘/a/b’, ‘/a/b/101’}|
|R| = 2 = |{‘/a/b’, ‘/a/b/101’}|
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)

30. Prefix Exclusion : Results
Avg. number of links used per request, for request sizes
(BF size : 192 bit, table size : 107)
|F|=1 (max. aggregation)
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)
Ideal link usage levels if |R| reduced to 5 or less
… loss of aggregation levels implies larger table sizes, and thus higher FP rates
Ideal 4

31. Improvement II : ‘Fallbacks’
Idea : If BF-based forwarding ‘doesn’t work’, request is forwarded using a secondary address
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)
Primary address : Bloom Filter-based content ID
BF = 1
IDorigin
Secondary address : If BF-based content ID doesn’t work, use ‘fallback’ address towards origin server

32. Fallbacks : When to use? Case 2 : Multiple matches detected!
Case 1 : Wrong delivery
Use fallback address (e.g., IDorigin)
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)
✔︎ Reduces link usage
✔︎ Reduces error resolution latency
✘ … at the cost of increase latency
Use fallback address (e.g., IDorigin)

33. Fallbacks : Cache Miss
Avg. number of links used per request & avg. latency
A single cache
for a single cache case
% of nodes surrounding the req. source which are caches
50%
% avg. latency
for 50% caches case
All
for All
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)
Ideal latency : 4 hops
~ ideal link usage
Ideal link
usage 4
Reduced delivery latency vs. short BFs
Reduced link usage vs. short BFs

34. Fallbacks : Multiple Match
Avg. number of links used per request & avg. latency
A single cache
for a single cache case
% of nodes surrounding the req. source which are caches
50%
% avg. latency
for 50% caches case
All
for All
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)
Reduced link usage 2
: Ideal latency
Ideal link usage 2
Increase in avg. latency vs. long BFs

35. Outline Hierarchical names, flat IDs and aggregation
Packet Forwarding with Bloom Filters
Impact of False Positive matches in Bloom Filters
Evaluation in Realistic Topologies
Conclusions
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)

36. Conclusions
Analyzed correctness of BF-based forwarding in realistic topologies
Identified aggregation vs. feasibility trade-off:
Forwarding errors are more likely with higher levels of aggregation
High link usage with 192 BFs (as suggested in literature)
Increasing BF size to 384 bit improves forwarding correctness
Prefix exclusion promising to improve forwarding correctness
Increases FIB sizes, which may offset its benefits
Fallbacks reduce link usage for smaller BF sizes
At the cost of increased latency
Bloom Filters can be useful to scalability by introducing aggregation, in a similar way to Named Data Networking (NDN)