Web Caching on Smartphones: Ideal vs. Reality
Feng Qian1, Kee Shen Quah1, Junxian Huang1, Jeffrey Erman2
Alexandre Gerber2, Z. Morley Mao1, Subhabrata Sen2, Oliver Spatscheck2
1University of Michigan 2AT&T Labs - ResearchJune 27 2012
Mobile Traffic: An Explosive Growth
• Deployment of cellular infrastructures: much slower– Spectrum shortage and economic issue– The cellular infrastructure spending in 2011 was expected
to be only a 6.7% rise over 2010
Year 2011 2012 2013 2014 2015 2016
Global Mobile Data Traffic per Month (106 TB)
0.6 1.3 2.4 4.2 6.9 10.8
Avg. Smartphone Traffic per Month
(MB)150 2576
Source: Cisco Visual Networking Index (VNI) Global Mobile Data Traffic Forecast, 2011-2016
1600% increase
2
Web Caching on Cellular Devices
• The big picture: traffic redundancy elimination• The first network-wide study of redundant transfers
caused by inefficient HTTP caching on cellular devices– HTTP: The dominant app-layer protocol for ~20 years– Caching: Huge benefits, but complex– Caching on cellular devices:
Reduces redundant data transferred over the RANImproves performance due to reduced latencyCuts cellular bills for customers
3
Background: Caching in HTTP 1.1
• Use Expiration and Revalidation to ensure caching consistency• Before expiration: the client should safely assume the
freshness of the cached file• After expiration: the client must send a revalidation message
to the server to query the freshness of the cache entry
4
Last-Modified: Feb 1 2012 15:00:00Expires: Feb 10 2012 15:00:00
If-Modified-Since:Feb 1 2012 15:00:00?304 Not Modified
Last-Modified: Feb 12 2012 15:00:00Expires: Feb 15 2012 15:00:00
Last-Modified: Feb 1 15:00:00Expires: Feb 10 15:00:00
Last-Modified: Feb 12 15:00:00Expires: Feb 15 15:00:00
Well known protocol for 20 yearsWhat is the state-of-the-art in the context of cellular devices?
Measurement Goal
• Goal: understand the state-of-the-art inHTTP caching on cellular devices
• What to study: redundant transfers caused by inefficient HTTP caching
• Potential cause: HTTP implementation Related– Caching logic (client/server) not following HTTP spec– Limited cache size– Non-persistent cache
• Potential cause: application semantics related– Server conservatively sets headers to make files uncacheable
or expire too soon
5
They account for 20% of the total HTTP traffic volume!
Measurement DataName ISP UMICH
Collection period May 20 2011 (24 hours) May to Oct 12 2011 (5 months)
Collection location Commercial cellular core network Directly on user handsets
Data format 695 million records of HTTP transactions
Full packet trace with payload of all traffic
Traffic volume 24.3 TB 118 GB
Dataset size 271 GB 119 GB
# Users About 2.9 million 20 U of Michigan students
Platforms Multiple (mainly iOS and Android) Android 2.2
User interface for the data collector/uploader software
6
Methodology
• A simulator strictly follows HTTP/1.1 caching logic (RFC 2616)– Expiration and freshness calculation mechanism – Non-cacheable objects– Partial caching due to byte-range requests and broken connection– LRU cache replacement algorithm, and more …
• Feed each user’s HTTP transactions to the cache simulator• Redundant transfers are accurately identified in the
simulation process• HTTP caching is not simple: 2K C++ LoC even for the
simulation core
7
Cacheability and Redundancy• File cacheability: for both datasets
– Most bytes (70% to 78%) and most files (66% to 72%) are cacheable.• Traffic Redundancy (assuming unlimited cache size)
• Root causes of redundant transfers (within all HTTP traffic)
8
Dataset % Redundancy(HTTP only)
% Redundancy(HTTP + non-HTTP)
ISP 17.7% N/AUMICH 20.3% 17.3%
Origin of redundancy ISP UMICH
1. Handset issues a request before local copies expire 15.9% 16.3%2. Handset does not revalidate after local copies expire(the file unchanged). 1.8% 4.0%
3. Server does not recognize revalidation after local copies expire (the file unchanged) <0.1% <0.1%
Under-estimationdue to HTTPS and app-semantic-related redundancy
ClientIssue
ServerIssue
Limited Cache Size andNon-persistent cache• Which factor has the main
responsibility for redundancy?– Problematic caching logic– Limited cached size: cache size ∞
4MB, HTTP traffic savings 17%13%– Non-persistent cache: 59% of
consecutive cache hits < 1 min• How large the cache size needs to
be?– A cache of 50 MB achieves 90% of
the gain (w.r.t. traffic reduction) compared to an unlimited cache
Dist. of intervals between consecutive cache hits on the same entry (ISP trace)
9
The benefits are significant even for a small cache.
It is unlikely that the handset is rebooted during such a short interval.
Quantifying the ResourceImpact of Redundant Traffic
• In cellular networks, we also care about cellular resources• Use our trace-driven RRC state machine simulator with a
handset radio power model [Qian etal, Mobisys 11]– Applied to only cellular traffic within UMICH dataset
• Three important metrics characterizing cellular resource consumption:– D: radio resource consumption– S: signaling load– E: handset radio energy consumption
Compute the impact: ΔE = (E0 – ER) / E0
E0: Radio energy consumption
in original traces
ER: Radio energy consumption in modified
traces with redundant transfers removed
ΔE: Radio energy impact of
redundant transfers (a positive value)
10
Quantifying the ResourceImpact of Redundant Traffic
• When redundant and other traffic coexist, only eliminating redundant traffic may not reduce resource consumption– As long as one of the concurrent transfers exists, the radio
is on (i.e., consuming resources)• Non-HTTP traffic plays a role (push notification and chatting)
– Traffic volume: small (1%); resource impact: high (18%)– Resource release is controlled by fixed inactivity timers– Sending small data incurs high resource overhead
ΔS Signaling load Impact
ΔE Radio Energy Impact
ΔD Radio Resource Impact
HTTP only 27% 26% 27%All traffic 6% 7% 9%
11
Testing HTTP Libraries and Browsers• Verify measurement findings by testing popular
HTTP libraries and browsers on real handsets• Design 13 controlled tests to cover all important
aspects of caching implementationFeature tests (is it well supported?)1. Basic caching2. Revalidation3. Various non-caching directives4. Various expiration directives5. URL with query strings6. Partial caching7. Redirection caching
Attribute tests (infer the parameters)1. Shared or non-shared?2. Persistent or non-persistent?3. Cache entry size limit4. Total cache size5. Cache entry replacement policy6. Heuristic freshness lifetime
12
• Revisit: which factor has the main responsibility for redundancy?– Problematic caching logic– Limited cached size– Non-persistent cache
Testing HTTP Libraries and Browsers
• Basic caching test– Handset requests for a small cacheable file f– Server transfers f with a proper Expires directive.– Client requests for f again before it expires.– PASS iff the 2nd request not incurring any network traffic
• Cache size test: perform binary search• Cache replacement policy test: try popular
algorithms (LRU, LFU, FIFO)• See paper for all 13 tests
13
Test ResultsSmartphone HTTP library OS version Support
Caching?Caching
Enabled by Default?
java.net.URLConnection Android 2.3 No No
java.net.HttpURLConnection Android 2.3 No No
org.apache.http.client.HttpClient Android 2.3 No No
android.webkit.WebView Android 2.3 Yes No
android.net.http.HttpResponseCache Android 4.0.2 Partially No
Three20 (Version 1.0.6.2) iOS 4.3.4 No No
NSURLRequest iOS 5.0.1 Partially No
ASIHTTPRequest (Version 1.8.1) iOS 4.3.4 Partially No
Android Browser Android 2.3 Partially Yes
iPhone Browser iOS 4.3.4/5.0.1 Partially Yes
Chrome Browser Android 4.0.2 YES YES
Implementation issues of caching
• 4 out of 8 libraries do not support caching at all.• For both browsers, when loading the same URL
back-to-back, the second request is treated as a full reload from the remote server
• Android browser uses a small cache of 8MB• Partial caching is not supported• Some do not properly handle Pragma:no-cache or
Cache-Control:no-cache.• …
A huge gap between protocol specification and implementation, leading to significant redundancy of network traffic.
14
Summary• The first network-wide study of cellular HTTP
caching• Redundant transfers are prevalent
– 18% (ISP) and 20% (UMICH) of HTTP traffic volume– 17% of overall traffic volume (UMICH)– 6%~9% of cellular resource consumption (UMICH)– The root cause: problematic caching logic on
handsets– Validated by caching tests of popular libraries and
browsers
15
Backup Slides
Diversity Among Applications• Identifying smartphone applications
– ISP: by user-agent fields in HTTP requests– UMICH: by the captured packet-process correspondence
• Diversity among top apps– HTTP redundancy ratios range from 0.0% to 100.0%
• Validate apps with high redundancy ratios (> 90%) – Analyze locally collected tcpdump traces– They do not cache HTTP responses
• Some apps have negligible redundant transfers– Almost all bytes are not cacheable
e.g., all requests are HTTP POST instead of HTTP GET
17
The Cache Simulator (Simplified Version)18
The simulation algorithm:• Performs fine-grained
caching simulation at a per-user basis
• Assigns to each HTTP transaction a label indicating its caching status.
• Red labels correspond to duplicated transfers.
foreach HTTP transaction r if (file is not storable) then assign_label(r, NOT_STORABLE); continue; else if (cache entry not exists) then assign_label(r, CACHE_ENTRY_NOT_EXIST); else if (cache entry not expired) then assign_label(r, NOT_EXPIRED_DUP); continue; else if (file changed) then assign_label(r, FILE_CHANGED); else if (HTTP 304 used) then assign_label(r, HTTP_304); else if (revalidation not performed) then assign_label(r, EXPIRED_DUP); else assign_label(r, EXPIRED_DUP_SVR); update_cache_entry(r);endfor
The file contains "Cache-Control: no-store“. It cannot be cached.Cache miss.Duplicated transfer: A request is issued before the file expires.The file has changed after the cache entry expires.
The file has not changed after the cache entry expires, and a cache revalidation is properly performed.
Duplicated transfer: the file has not changed after the cache entry expires, but the handset does not perform cache revalidation.
Duplicated transfer: the file has not changed after the cache entry expires, but the server does not recognize the cache revalidation.
Background: Radio Resource Management in Cellular Networks
• RRC (Radio Resource Control) state machine [3GPP TS 25.331]
– State promotions have promotion delay– State demotions incur tail times
Tail Time
Tail Time
Delay: 1.5sDelay: 2s RRC State Channel Radio
Power
IDLE Not allocated
Almost zero
CELL_FACH Shared, Low Speed Low
CELL_DCH Dedicated, High Speed High
UMTS RRC State Machine for a large US 3G carrier Page 19
Background: Radio Resource Management in Cellular Networks
Promo Delay2 Sec
DCHTail
5 sec
FACHTail
12 sec
Tail TimeWaiting inactivity timers to expire
Page 20