smartre : an architecture for coordinated network-wide redundancy elimination
Post on 23-Mar-2016
47 Views
Preview:
DESCRIPTION
TRANSCRIPT
1
SmartRE: An Architecture for Coordinated Network-Wide
Redundancy Elimination
Ashok Anand, Vyas Sekar, Aditya Akella
University of Wisconsin, MadisonCarnegie Mellon University
2
Redundancy Elimination (RE) for Increasing Network Capacity
EnterprisesMobile Users Home Users
Web content
HTTPcaches
HTTPcaches
HTTPcaches
Data centers
Wan Optimizer
Wan Optimizer
Other services(backup)
Dedup/archival
Dedup/archival
Video
CDNCDN
CDNRE: Leverage repeated transmissions Many “narrow” solutions to improve performance!
Can we generalize this transparently?Benefit both users and ISPs?
3
In-Network RE as a Service
Routerskeep a cache of recent pkts
New packets get “encoded” or “compressed”
w.r.t cached pkts
Encoded pkts are“decoded” or
“uncompressed”downstream
Key Issues:1. Performance: Minimize Traffic FootPrint (“byte-hops”)
2. Cache Capacity: Can only provision finite DRAM3. Processing Constraints: Enc/Dec are memory-access limited
RE as a IP-layer service: Generalizes “narrow” deploymentsTransparent to users/apps: Democratizes benefits of RE
Benefits ISPs: Better TE/Lower load
4
In-Network RE as a ServiceHop-by-Hop (Anand et al, Sigcomm08)
Performance (Leverage all RE) ✔Cache Constraints ✖
Processing Constraints ✖
Encode
Decode
Encode
Encode Encode
Encode
Decode
Decode
Decode
Decode
Same packetencoded and decoded
many times
Same packetcached
many times
Hop-by-hop RE is limited by encoding bottleneck Encoding: ~ 15 mem. accesses ~ 2.5 Gbps (@ 50ns DRAM)Decoding: ~ 3-4 accesses > 10 Gbps (@ 50ns DRAM)
5
Encode Decode
DecodePerformance (Leverage all RE) ✖
Cache Constraints ✔Processing Constraints ✔
Cannotleverage
Inter-path RE
Canleverage
Intra-path RE
In-Network RE as a ServiceAt the Edge
Doesn’t help ISPs (e.g., traffic engineering)
6
Motivating Question:How can we practically leverage the
benefits of network-wide RE optimally?
Edge Hop-by-Hop
Performance (Leverage all RE) ✖ ✔Cache Constraints ✔ ✖
Processing Constraints ✔ ✖
7
Outline
• Background and Motivation
• High-level idea
• Design and Implementation
• Evaluation
8
SmartRE: High-level ideaDon’t look at one-link-at-a-time
Treat RE as a network-wide problem
Cache Constraints:“Coordinated Caches”Each packet is cached
only oncedownstream
Processing Constraints:Encode @ Ingress,
Decode@ Interior/Egress Decode can occur
multiple hopsafter encoder
Performance: Network-Wide Optimization Account for
traffic, routing, constraints etc.
SmartRE: Coordinated Network-wide RE
9
Cache Constraints ExamplePacket arrivals: A, B, A,B
Ingress can store 2pktsInterior can store 1pkt
A,BB,AA,B
BAB
BAB
After 2nd pkt
After 4th pkt
Total RE savings in network footprint (“byte hops”)?
RE on first linkNo RE on interior
2 * 1 = 2
Can we do better than this?
10
Cache Constraints ExampleCoordinated Caching
Packet arrivals: A, B, A,B
Ingress can store 2pktsInterior can store 1pkt
A,BA,BA,B
AAA
BBB
After 2nd pkt
1 * 2 + 1 * 3 = 5
RE for pkt ASave 2 hops
RE for pkt BSave 3 hops
After 4th pkt
Total RE savings in network footprint (“byte hops”)?
11
Dec
Processing Constraints Example
Enc
Dec
Enc
Enc Enc
Dec
Dec
Dec
4 Mem Ops for Enc2 Mem Ops for Dec
5 Enc/s
5 Dec/s5 Enc/s
5 Dec/s 5 Enc/s 5 Enc/s5Dec/s
5Dec/s
Total RE savings in network footprint (“byte hops”)?
5 * 6 = 30 units/s
Note that even though decoders can do more work, they are limited
by encoders
20 Mem Ops
Enc5 Enc/s
Dec5 D/sEnc5 Dec/s 5 E/s
Can we do better than this?
12
5 Dec/s
Processing Constraints Example:Smarter Approach
4 Mem Ops for Enc2 Mem Ops for Dec
5 Enc/s
5 Enc/s
10 Dec/s
Total RE savings in network footprint (“byte hops”)?
10*3 + 5 *2 = 40 units/s
20 Mem Ops
5 Dec/s5 Enc/s
Dec @ edge Dec @ core
Many nodes are idle.Still does better!Good for partial deployment also
13
Outline
• Background and Motivation
• High-level idea
• Design and Implementation
• Evaluation
14
SmartRE OverviewNetwork-Wide Optimization
“Encoding Configs” To Ingresses
@ NOC
“Decoding Configs” To Interiors
15
Ingress/Encoder Operation
EncodingConfig
PacketCache
Check if this packet needs to be cached
Identify candidate packets to encode
Find “compressible” regions w.r.t cached packetsSpring & Wetherall Sigcomm’00, Anand et al Sigcomm’08
Shim carriesInfo(matched pkt)MatchRegionSpec
16
Interior/Decoder Operation
DecodingConfig
PacketCache
Check if this packet needs to be cached
Reconstruct “compressed” regions using reference packets
Shim carriesInfo(matched pkt)MatchRegionSpec
17
Design Components
How do we specify coordinated caching responsibilities?
Correctness:How do ingresses and interior nodes maintain cache consistency?
How do ingresses identify candidate packets for encoding?
What does the optimization entail?
18
18
How do we “coordinate” caching responsibilities across routers ?
Non-overlapping hash-ranges per-path avoids redundant caching!(from cSamp, NSDI 08)
[0.1,0.4][0.7,0.9]
[0.7,0.9]
[0.1,0.4]
[0,0.3]
[0.1,0.3]
[0,0.1]
1. Hash (pkt.header)2. Get path info for pkt3. Cache if hash in range for path
19
Design Components
How do we specify coordinated caching responsibilities?
Correctness:How do ingresses and interior nodes maintain cache consistency?
How do ingresses identify candidate packets for encoding?
What does the optimization entail?
20
Network-wide optimization
Traffic PatternsTraffic MatrixRedundancy Profile(intra + inter)
Router constraints Processing (MemAccesses)Cache Size
Encoding manifestsDecoding manifests
Objective:Max. Footprint Reduction (byte-hops)
or any ISP objective (e.g., TE)LinearProgram
Inputs
Output
What does the “optimization” entail?
Topology Routing Matrix Topology Map Path,HashRange
21
Design Components
How do we coordinate caching responsibilities across routers ?
Correctness:How do ingresses and interior nodes maintain cache consistency?
How do ingresses identify candidate packets for encoding?
What does the optimization entail?
22
[0.1,0.4][07,0.9]
[0.7,0.9]
[0.1,0.4]
[0,0.3]
[0.1,0.3]
[0,0.1]
How do ingresses and interior nodes maintain cache consistency?
What if traffic surge on red path causes packets on black path to be
evicted?
Create “logical buckets”For every path-interior pair Evict only within buckets
23
Network-Wide Optimization @ NOCRoutingRedundancy ProfileTraffic Device Constraints
SmartRE: Putting the pieces together
“Encoding Configs” To Ingresses
“Decoding Configs” To Interiors
[0.1,0.4][07,0.9]
[0.7,0.9]
[0.1,0.4]
[0,0.3]
[0.1,0.3]
[0,0.1]
Cache Consistency:Create “logical buckets”
For every path-interior pair Evict only within buckets
Non-overlapping hash-ranges per-path avoids redundant caching!
Candidate packets must be available on
new packet’s path
24
Outline
• Background and Motivation
• High-level idea
• Design and Implementation
• Evaluation
25
Reduction in Network Footprint
SmartRE is 4-5X better than the Hop-by-Hop Approach
SmartRE gets 80-90% of ideal unconstrained RE
Results consistent across redundancy profiles, on synthetic traces
Setup: Real traces from U.WiscEmulated over tier-1 ISP topologies
Processing constraints MemOps & DRAM speed2GB cache per RE device
26
More results …
Can we benefit even with partial deployment? Even simple strategies work pretty well!
What if redundancy profiles change over time? Some “dominant” patterns which are stable
Get good performance even with dated configs
27
To Summarize ..• RE as a network service is a promising vision
– Generalizes specific deployments: benefit all users, apps, ISPs
• SmartRE makes this vision more practical– Look beyond link-local view; decouple encoding-decoding – Network-wide coordinated approach
• 4-5X better than current proposals– Works even with less-than-ideal/partial deployment
• Have glossed over some issues ..– Consistent configs, Decoding gaps, Packet losses, Routing dynamics
• Other domains: Data Center Networks, Multihop Wireless etc.
top related