180 Park Ave - Building 103
Florham Park, NJ
To Cache or not to Cache: The 3G case
Jeffrey Erman, Alexandre Gerber, Mohammad Hajiaghayi, Dan Pei, Subhabrata Sen, Oliver Spatscheck
IEEE Internet Computing,
2011.
[PDF]
[BIB]
IEEE Copyright
This version of the work is reprinted here with permission of IEEE for your personal use. Not for redistribution. The definitive version was published in IEEE Internet Computing, 2011. , 2011-01-01
{Cellular networks have witnessed tremendous traffic growth
recently, fueled by the rapid proliferation of smartphones,
laptops with mobile data cards, and new technologies improving
the performance of these networks. However, unlike
the wired world, there exists a rather limited understanding
of the application mixes and the characteristics of this traffic.
Recent studies have shown that in the wired broadband
world, HTTP traffic accounts for the vast majority of the application
traffic and that forward caching of HTTP objects
results in substantial savings in network resources. What
about cellular networks? The answer is a function of the
traffic characteristics, network architecture, as well as the
various cost points associated with delivering traffic in these
networks. In this paper, we examine the characteristics of
HTTP traffic generated by millions of users across one of
the world�s largest 3G cellular networks, and explore the potential
of forward caching. We provide a simple cost model
that third parties can easily use to determine the cost-benefit
tradeoffs for their own cellular network settings. This is the
first large scale caching analysis in cellular networks.}
Quantifying the Extent of IPv6 Deployment
Elliott Karpilovsky, Alexandre Gerber, Dan Pei, Jennifer Rexford, Aman Shaikh
in Proc. Passive and Active Measurement Conference (PAM),
2009.
[BIB]
{Internet routers� forwarding tables (FIBs), which must be stored in
expensive fast memory for high-speed packet forwarding, are growing quickly in
size due to increased multihoming, finer-grained traffic engineering, and deployment
of IPv6 and VPNs. To address this problem, several Internet architectures
have been proposed to reduce FIB size by leveraging route caching: storing only
the working set of popular routes in the FIB. This paper revisits route caching.
We build upon previous work by studying flat, uni-class (/24) prefix caching, with
modern traffic traces from more than 60 routers in a tier-1 ISP. We first characterize
routers� working sets and then evaluate route-caching performance under
different cache replacement strategies and cache sizes. Surprisingly, despite the
large number of deaggregated /24 subnets, caching uni-class prefixes can effectively
curb the increase of FIB sizes. Moreover, uni-class prefixes substantially
simplify a cache design by eliminating longest-prefix matching, enabling FIB
design with slower memory technologies. Finally, by comparing our results with
previous work, we show that the distribution of traffic across prefixes is becoming
increasingly skewed, making route caching more appealing.}
Network-Aware Forward caching
Jeffrey Erman, Alexandre Gerber, Mohammad Hajiaghayi, Dan Pei, Oliver Spatscheck
in Proc. World Wide Web Conference (WWW),
2009.
[PDF]
[BIB]
IW3C2 Copyright
"Copyright is held by the International World Wide Web Conference Committee (IW3C2)."
{This paper proposes and evaluates a Network Aware Forward
Caching approach for determining the optimal deployment strategy
of forward caches to a network. A key advantage of this approach
is that we can reduce the network costs associated with forward
caching to maximize the benefit obtained from their deployment.
We show in our simulation that a 37% increase to net benefits could
be achieved over the standard method of full cache deployment to
cache all POPs traffic. In addition, we show that this maximal point
occurs when only 68% of the total traffic is cached.
Another contribution of this paper is the analysis we use to motivate
and evaluate this problem. We characterize the Internet traffic
of 100K subscribers of a US residential broadband provider. We
use both layer 4 and layer 7 analysis to investigate the traffic volumes
of the flows as well as study the general characteristics of
the applications used. We show that HTTP is a dominant protocol
and account for 68% of the total downstream traffic and that 34%
of that traffic is multimedia. In addition, we show that multimedia
content using HTTP exhibits a 83% annualized growth rate and
other HTTP traffic has a 53% growth rate versus the 26% over all
annual growth rate of broadband traffic. This shows that HTTP
traffic will become ever more dominant and increase the potential
caching opportunities. Furthermore, we characterize the core
backbone traffic of this broadband provider to measure the distance
traveled by content and traffic. We find that CDN traffic is much
more efficient than P2P content and that there is large skew in the
Air Miles between POP in a typical network. Our findings show
that there are many opportunities in broadband provider networks
to optimize how traffic is delivered and cached.}
Scalable VPN Routing via Relaying
Changhoon Kim, Alexandre Gerber, Carsten Lund, Dan Pei, Subhabrata Sen
in Proc. ACM SIGMETRICS,
2008.
[PDF]
[BIB]
ACM Copyright
(c) ACM, 2008. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in ACM SIGMETRICS 2008 , 2008-06-06.
{Enterprise customers are increasingly adopting MPLS(Multiprotocol Label Switching) VPN (Virtual Private Network) service that offers direct any-to-any reachability among the customer sites via a provider network. Unfortunately this direct reachability model makes the service provider's routing tables grow very large as the number of VPNs and the number of routes per customer increase. As a result, router memory in the provider's network has become a key bottleneck in provisioning new customers. This paper proposes Relaying, a scalable VPN routing architecture that the provider can implement simply by modifying the configuration of routers in the provider network, without requiring changes to the router hardware and software. Relaying substantially reduces the memory footprint of VPNs by choosing a small number of hub routers in each VPN that maintain full reachability information, and by allowing nonhub routers to reach other routers through a hub. Deploying Relaying in practice, however, poses a challenging optimization problem that involves minimizing router memory usage by having as few hubs as possible, while limiting the additional latency due to indirect delivery via a hub. We first investigate the fundamental tension between the two objectives and then develop algorithms to solve the optimization problem by leveraging some unique properties of VPNs, such as sparsity of traffic matrices and spatial locality of customer sites. Extensive evaluations using real traffic matrices, routing configurations, and VPN topologies demonstrates that Relaying is very promising and can reduce routing-table usage by up to 90%, while increasing the additional distances traversed by traffic by only a few hundred miles, and the backbone bandwidth usage by less than 10%. }
Network-Aware Forward caching
Alexandre Gerber, Jeffrey Erman, Mohammad Hajiaghayi, Dan Pei, Oliver Spatscheck
2008.
[PPT]
[BIB]
Scalable Multiprotocol Label Switching Based Virtual Private Networks And Methods To Implement The Same,
Tue Sep 14 15:04:40 EDT 2010
Example scalable multi-protocol label switching (MPLS) based virtual private networks (VPNs) and methods to implement the same are disclosed. A disclosed example spoke provider edge (PE) router for an MPLS-based VPN includes a truncated virtual routing and forwarding (VRF) table containing a first value referencing a hub PE router and a second value referencing a first customer edge (CE) router coupled to the VPN via the PE router, and a forwarding module to forward a packet received from the first CE router to the hub PE router when the packet contains an address referencing a second CE router coupled to the VPN via a second spoke PE router.
