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 adamiaonr@cmu.edu prs@cs.cmu.edu anaa@fe.up.pt Carnegie Mellon University, PA, USA1 University of Porto, Portugal2 Instituto de Telecomunicações, Portugal3 2018-09-23

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

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

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 FIB @R1 prefix next hop /acme R2 FIB @R1 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

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

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

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

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 ✘

Bloom Filters : Routing & aggregation Routing & prefix aggregation RIB @R6 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 FIB @R6 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

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

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

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?

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?

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

Network-level Impact of FPs /b |FP|=|TP| ✔︎ R1 R2 ✔︎ FIB @{R6} 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?

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

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

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

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

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)

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)

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

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

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

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

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

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

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)

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)

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

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

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)

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

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

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)

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)