SmartRE: An Architecture for Coordinated Network-Wide Redundancy Elimination Ashok Anand, Vyas Sekar, Aditya Akella University of Wisconsin, Madison Carnegie.

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.