A System for Coordinated Network-wide Redundancy Elimination
Ashok Anand, Vyas Sekar, Aditya Akella · 2008
Motivation: Today, an increasing number of end-networks are deploying redundancy elimination (RE) solutions to improve their WAN performance. The success of such deploymentshasmotivatedresearchers,equipmentvendors(e.g.,Cisco, Riverbed) and ISPs to explore the potential of network-wide RE. Recent work [1] has shown the benefits of supporting RE as a primitive IP-layer service on network routers. In similar vein, network equipment vendors have highlighted the network-wide support for content caching as a key focus area. Supporting RE at the network-level socializes the benefits of RE to all end-to-end flows and also allows ISPs to better handle bandwidth-intensive workloads. While the problemof RE has been well studied in the context of point deployments(e.g. over a single WAN link of an enterprise network), there has been relatively little work on how to best design network-wide RE deployments. Extending such single vantage point solutions to the network-wide case, as proposed by Anand et. al [1], does not take into account the resource constraints on RE devices. This severely constrainsthe benefits that end applicationsand ISPs can derive from network-wide RE. In this work, we explore how to build effective and practical network-wide RE systems. We present Decor, a coordinated system-wide architecture for in-network RE. Decor allows packets to be decoded at routers multiple hops away from the routerwhere packet was encoded. This allows us to utilize resources from different routers for decoding. Decor takes into account the ISP’s objectives (e.g., network-wide footprint reduction) and the resource constraints of different RE devices, to optimally allocate caching and decoding responsiblities. While our current focus has primarily been on RE in ISPs, our design can be more broadly applied to data-center and multi-hop wireless networks. Design and Implementation: We focus our design on three key elements: ingress, interior nodes and a central configuration model (Figure 1). Ingress nodes encode packets with respect to earlier seen packets in the cache. Interior routers lookup their cache to decode the encoded packet. We leverage ideas from cSamp [2] to split the caching responsibilities for interior routers in terms of hash-range per path per router. Each interior router is responsible for caching those packets whose header’s hash falls in the assigned range for the path. This information is specified by a caching manifest produced by the central configuration module. The central