Analysis and Improvement of Name-based Packet
NS
Published · 36 slides · 0 views
1 / 1
Description
Analysis and Improvement of Name-based Packet Forwarding over Flat ID Network Architectures 2018-09-23 Carnegie Mellon University, PA, USA1 University of Porto, Portugal2 Instituto de Telecomunicações, Portugal3 António Rodrigues1,2,3 Peter
Related Topics
Share
Embed code
Download this presentation From Below
"Analysis and Improvement of Name-based Packet" is the property of its rightful owner. Permission is granted to download and print the materials on this website for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation Transcript
01
Analysis and Improvement of
Name-based Packet Forwarding
over Flat ID Network Architectures 2018-09-23 Carnegie Mellon University, PA, USA1
University of Porto, Portugal2
Instituto de Telecomunicações, Portugal3 António Rodrigues1,2,3 Peter Steenkiste1 Ana Aguiar2,3 adamiaonr@cmu.edu prs@cs.cmu.edu anaa@fe.up.pt<br>
Name-based Packet Forwarding
over Flat ID Network Architectures 2018-09-23 Carnegie Mellon University, PA, USA1
University of Porto, Portugal2
Instituto de Telecomunicações, Portugal3 António Rodrigues1,2,3 Peter Steenkiste1 Ana Aguiar2,3 adamiaonr@cmu.edu prs@cs.cmu.edu anaa@fe.up.pt<br>
02
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<br>
Packet Forwarding with Bloom Filters
Impact of False Positive matches in Bloom Filters
Evaluation in Realistic Topologies
Conclusions<br>
03
Packet forwarding in ICNs:
Names vs. Flat* IDs Hierarchical names Flat IDs<br>
Names vs. Flat* IDs Hierarchical names Flat IDs<br>
04
Packet forwarding in ICNs:
Names vs. Flat* IDs Hierarchical names Flat IDs C1 get(/acme/A/101) or get(012b337) S2 ✘ No aggregation → no FIB scalability ✘ Needs a name-to-ID lookup service ✔︎ Fixed-sized content labels ✔︎ Aggregation → FIB scalability ✔︎ No need for name lookups Variable size content labels id of ‘/acme/A/101’?<br>
Names vs. Flat* IDs Hierarchical names Flat IDs C1 get(/acme/A/101) or get(012b337) S2 ✘ No aggregation → no FIB scalability ✘ Needs a name-to-ID lookup service ✔︎ Fixed-sized content labels ✔︎ Aggregation → FIB scalability ✔︎ No need for name lookups Variable size content labels id of ‘/acme/A/101’?<br>
05
Packet forwarding in ICNs:
Names vs. Flat* IDs Hierarchical names Flat IDs Can we bring the advantages of hierarchical names to flat ID architectures?<br>
Names vs. Flat* IDs Hierarchical names Flat IDs Can we bring the advantages of hierarchical names to flat ID architectures?<br>
06
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<br>
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<br>
07
3 sub-prefixes in ‘/a/b/c’ Bloom Filters : Name Encoding Hierarchical name encoding into Bloom Filters ✔︎ Fixed-sized content labels ✔︎ No name lookups hash(/a/b/c) hash(/a/) ‘/a/b/c’ hash(/a/b) ? Size of Request ID (RID) is the # of encoded sub-prefixes, or |R| = 3<br>
08
Bloom Filters : Lookups rid(/a/z)= rid(/a/b)= RIDs in FIB ✔︎ |F| iface 2 2 A C 1 1 1 1 1 1 RID in request packet ✘ TP match No match Lookups on FIB : Longest Prefix Matching (on names) using Bloom Filters ✔︎ Simple forwarding semantics ✔︎ Longest-prefix matching ✘ 1 1 1 1 1 1<br>
09
Bloom Filters : Routing & aggregation Routing & prefix aggregation /a/b /a/d /a prefix announcement link cost router /a/c Shortest path Aggregation ✔︎ Prefix aggregation cache /a/c /a /a/b /a/d<br>
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<br>
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<br>
11
The problem with Bloom Filters:
False Positive Matches<br>
False Positive Matches<br>
12
Router-level Impact of FPs How likely are forwarding errors C5 and C6? Forwarding outcomes<br>
13
C5: C6: Forwarding Errors in Practice What’s the impact of FP matches on a network level? ~ 1 FP per every 2 requests ~10s or FPs per request High # of FPs for max. levels of aggregation<br>
14
Network-level Impact of FPs /a/b /a /a/b /a ✔︎ request bf(/a/y/z) |FP|>|TP|<br>
15
Network-level Impact of FPs /b /a /b /a ✔︎ request bf(/a/y/z) ✔︎ ✔︎ ✔︎ ✔︎ What is the impact of FP matches in realistic networks? |FP|=|TP|<br>
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<br>
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<br>
17
BF-based Forwarding Model : Inputs /a Input 1 : Topology Input 2 : BF parameters request /*/*<br>
18
BF-based Forwarding Model : Outputs P([R1 … R5]) P([R1 … R6]) Avg. # of match events, at every router : Find every possible path for a request Probability of each path<br>
19
Evaluation : Setup Realistic topologies : PoP-level topologies from the Rocketfuel dataset [1] [1] : Spring et al., Measuring ISP topologies with Rocketfuel. In SIGCOMM '02 AT&T [1]<br>
20
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)) for each parameter combination
calculate average of model outputs over 20 <src, dst> pairs Evaluation : Methodology for each topology:
create 20 <src, dst> node pairs (paths)<br>
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)) for each parameter combination
calculate average of model outputs over 20 <src, dst> pairs Evaluation : Methodology for each topology:
create 20 <src, dst> node pairs (paths)<br>
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<br>
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<br>
22
Scenario 1 : Global Reachability Aggregation : all entries in FIBs :
size |F| = 1 (max. aggregation) or |F| = 5 Sources of requested content : 1 origin server Content space : Each node
serves 1/N * 107 entries Table size : 107 entries Request size : |R| = 10 Path lengths : 4 hops (to origin) Forwarding: Forward over all matching interfaces<br>
size |F| = 1 (max. aggregation) or |F| = 5 Sources of requested content : 1 origin server Content space : Each node
serves 1/N * 107 entries Table size : 107 entries Request size : |R| = 10 Path lengths : 4 hops (to origin) Forwarding: Forward over all matching interfaces<br>
23
Global Reachability:
Impact of BF & entry sizes Ideal 4 Ideal 4 |F|=1 (max. aggregation) |F|=5 Avg. number of links used per request Forwarding errors less likely from 384 bit up Link usage excess as high as 1000x for short BF sizes<br>
Impact of BF & entry sizes Ideal 4 Ideal 4 |F|=1 (max. aggregation) |F|=5 Avg. number of links used per request Forwarding errors less likely from 384 bit up Link usage excess as high as 1000x for short BF sizes<br>
24
Scenario 2 : Pro-active Caching I Cache size : Each node serves
1/N * 107 entries Caches added 2 hops from req. source Caches announce entries of
sizes |F| = 4 and 5 Table size : 107 entries Request size : |R| = 10 Content sources : 1 origin server Path lengths : 4 hops Aggregation : all entries in FIBs : size |F| = 1 (max. aggregation)<br>
1/N * 107 entries Caches added 2 hops from req. source Caches announce entries of
sizes |F| = 4 and 5 Table size : 107 entries Request size : |R| = 10 Content sources : 1 origin server Path lengths : 4 hops Aggregation : all entries in FIBs : size |F| = 1 (max. aggregation)<br>
25
A single cache 50% All Varying number of caches around
req. source: Caches added 2 hops from req. source Caches announce entries of
sizes |F| = 4 and 5 Scenario 2 : Pro-active Caching II<br>
req. source: Caches added 2 hops from req. source Caches announce entries of
sizes |F| = 4 and 5 Scenario 2 : Pro-active Caching II<br>
26
Pro-active Caching : Cache Miss Avg. number of links used per request & % of corr. deliveries 100 : Ideal deliv. % 4 Ideal link usage Caches are always picked over origin Forwarding errors are less likely due to low FP rates<br>
27
Pro-active Caching : Cache Hit Avg. number of links used per request & % of corr. deliveries 100 : Ideal deliv. % Ideal link usage 2 Only a single cache entry to choose from Forwarding errors are less likely due to low FP rates With more choices, more forwarding errors<br>
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<br>
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<br>
29
Improvement I : Prefix Exclusion Idea : Reduce the number of sub-prefixes encoded in RIDs<br>
30
Avg. number of links used per request, for request sizes
(BF size : 192 bit, table size : 107) Ideal 4 |F|=1 (max. aggregation) Prefix Exclusion : Results Ideal link usage levels if |R| reduced to 5 or less … loss of aggregation levels implies larger table sizes, and thus higher FP rates<br>
(BF size : 192 bit, table size : 107) Ideal 4 |F|=1 (max. aggregation) Prefix Exclusion : Results Ideal link usage levels if |R| reduced to 5 or less … loss of aggregation levels implies larger table sizes, and thus higher FP rates<br>
31
Improvement II : ‘Fallbacks’ Idea : If BF-based forwarding ‘doesn’t work’, request is forwarded using a secondary address IDorigin Secondary address : If BF-based content ID doesn’t work, use ‘fallback’ address towards origin server Primary address : Bloom Filter-based content ID<br>
32
Fallbacks : When to use? Use fallback address (e.g., IDorigin) Use fallback address (e.g., IDorigin) ✔︎ Reduces error resolution latency Case 1 : Wrong delivery Case 2 : Multiple matches detected! ✔︎ Reduces link usage ✘ … at the cost of increase latency<br>
33
Fallbacks : Cache Miss A single cache 50% All % of nodes surrounding the req. source which are caches % avg. latency for a single cache case for 50% caches case for All Avg. number of links used per request & avg. latency 4 Ideal latency : 4 hops Ideal link
usage Reduced link usage vs. short BFs Reduced delivery latency vs. short BFs ~ ideal link usage<br>
usage Reduced link usage vs. short BFs Reduced delivery latency vs. short BFs ~ ideal link usage<br>
34
Fallbacks : Multiple Match A single cache 50% All % of nodes surrounding the req. source which are caches % avg. latency for a single cache case for 50% caches case for All Ideal link usage Avg. number of links used per request & avg. latency 2 2 : Ideal latency Increase in avg. latency vs. long BFs Reduced link usage<br>
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<br>
Packet Forwarding with Bloom Filters
Impact of False Positive matches in Bloom Filters
Evaluation in Realistic Topologies
Conclusions<br>
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<br>
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<br>