SmartRE : An Architecture for Coordinated Network-Wide Redundancy Elimination

1. SmartRE: An Architecture for Coordinated Network-WideRedundancy Elimination Ashok Anand, Vyas Sekar,AdityaAkella University of Wisconsin, Madison Carnegie Mellon University

2. Redundancy Elimination (RE) for Increasing Network Capacity Data centers Other services(backup) Video Web content CDN Dedup/archival RE: Leverage repeated transmissions Many “narrow” solutions to improve performance! Wan Optimizer HTTP caches CDN HTTP caches HTTP caches Wan Optimizer CDN Can we generalize this transparently? Benefit both users and ISPs? Dedup/archival Mobile Users Home Users Enterprises

3. In-Network RE as a Service Key Issues: Performance: Minimize Traffic FootPrint (“byte-hops”) 2. Cache Capacity: Can only provision finite DRAM 3. Processing Constraints: Enc/Dec are memory-access limited New packets get “encoded” or “compressed” w.r.t cached pkts Encoded pkts are “decoded” or “uncompressed” downstream Routers keep a cache of recent pkts 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) 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) Decode Encode Decode Decode Encode Encode Encode Decode Same packet cached many times Same packet encoded and decoded many times Decode Encode

5. In-Network RE as a ServiceAt the Edge Doesn’t help ISPs (e.g., traffic engineering) Cannot leverage Inter-path RE Decode Encode Can leverage Intra-path RE Decode

6. Motivating Question:How can we practically leverage the benefits of network-wide RE optimally?

7. Outline • Background and Motivation • High-level idea • Design and Implementation • Evaluation

8. SmartRE: High-level idea Don’t look at one-link-at-a-timeTreat RE as a network-wide problem Processing Constraints:Encode @ Ingress, Decode@ Interior/Egress Decode can occur multiple hopsafter encoder Cache Constraints:“Coordinated Caches”Each packet is cached only once downstream Performance: Network-Wide Optimization Account for traffic, routing, constraints etc. SmartRE: Coordinated Network-wide RE

9. Cache Constraints Example Packet arrivals: A, B, A,B Ingress can store 2pkts Interior can store 1pkt Total RE savings in network footprint (“byte hops”)? After 2ndpkt After 4thpkt Can we do better than this? B A B A,B B,A A,B B A B 2 * 1 = 2 RE on first link No RE on interior

10. Cache Constraints Example Coordinated Caching Packet arrivals: A, B, A,B Ingress can store 2pkts Interior can store 1pkt Total RE savings in network footprint (“byte hops”)? After 2ndpkt B B B A,B A,B A,B After 4thpkt A A A 1 * 2 + 1 * 3 = 5 RE for pkt A Save 2 hops RE for pkt B Save 3 hops

11. Processing ConstraintsExample Note that even though decoders can do more work, they are limited by encoders 4 Mem Ops for Enc 2 Mem Ops for Dec 20 Mem Ops Enc 5Dec/s Dec 5 Enc/s 5 Enc/s Enc Dec 5 Dec/s 5Dec/s Dec 5 Enc/s Enc 5 Enc/s Enc 5 D/s 5 Dec/s Dec Dec 5 E/s Enc Dec 5 Dec/s Can we do better than this? 5 Enc/s Enc Total RE savings in network footprint (“byte hops”)? 5 * 6 = 30 units/s

12. Processing ConstraintsExample: Smarter Approach 4 Mem Ops for Enc 2 Mem Ops for Dec Many nodes are idle.Still does better! Good for partial deployment also 20 Mem Ops 10 Dec/s 5 Enc/s 5 Dec/s 5 Dec/s 5 Enc/s Total RE savings in network footprint (“byte hops”)? 5 Enc/s 10*3 + 5 *2 = 40 units/s Dec @ edge Dec @ core

13. Outline • Background and Motivation • High-level idea • Design and Implementation • Evaluation

14. SmartRE Overview @ NOC Network-Wide Optimization “Encoding Configs” To Ingresses “Decoding Configs” To Interiors

15. Ingress/Encoder Operation Packet Cache Encoding Config Shim carriesInfo(matchedpkt) MatchRegionSpec 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

16. Interior/Decoder Operation Packet Cache Decoding Config Shim carriesInfo(matchedpkt) MatchRegionSpec Check if this packet needs to be cached Reconstruct “compressed” regions using reference packets

17. Design Components How do we specify coordinated caching responsibilities? What does the optimization entail? Correctness:How do ingresses and interior nodes maintain cache consistency? How do ingresses identify candidate packets for encoding?

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.1,0.3] [0.1,0.4] [0,0.1] [0.7,0.9] [0,0.3] Hash (pkt.header) Get path info for pkt Cache if hash in range for path 18

19. Design Components How do we specify coordinated caching responsibilities? What does the optimization entail? Correctness:How do ingresses and interior nodes maintain cache consistency? How do ingresses identify candidate packets for encoding?

20. What does the “optimization” entail? Objective: Max. Footprint Reduction (byte-hops) or any ISP objective (e.g., TE) Inputs Traffic Patterns Traffic Matrix Redundancy Profile (intra + inter) Linear Program Output Encoding manifests Decoding manifests Network-wide optimization Topology Routing Matrix Topology Map Path,HashRange Router constraints Processing (MemAccesses) Cache Size

21. Design Components How do we coordinate caching responsibilities across routers ? What does the optimization entail? Correctness:How do ingresses and interior nodes maintain cache consistency? How do ingresses identify candidate packets for encoding?

22. How do ingresses and interior nodes maintain cache consistency? What if traffic surge on red path causes packets on black path to be evicted? [0.1,0.4] [07,0.9] [0.1,0.3] [0.1,0.4] [0,0.1] [0.7,0.9] [0,0.3] Create “logical buckets” For every path-interior pair Evict only within buckets

23. SmartRE: Putting the pieces together Traffic Redundancy Profile Routing Device Constraints @ NOC Network-Wide Optimization “Encoding Configs” To Ingresses “Decoding Configs” To Interiors Candidate packets must be available on new packet’s path [0.1,0.4] [07,0.9] [0.1,0.3] Cache Consistency:Create “logical buckets” For every path-interior pair Evict only within buckets [0.1,0.4] [0,0.1] [0,0.3] [0.7,0.9] Non-overlapping hash-ranges per-path avoids redundant caching!

24. Outline • Background and Motivation • High-level idea • Design and Implementation • Evaluation

25. Reduction in Network Footprint Setup: Real traces from U.Wisc Emulated over tier-1 ISP topologies Processing constraints MemOps & DRAM speed 2GB cache per RE device 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

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.