1 / 20

Web Caching on Smartphones: Ideal vs. Reality

Web Caching on Smartphones: Ideal vs. Reality . Feng Qian 1 , Kee Shen Quah 1 , Junxian Huang 1 , Jeffrey Erman 2 Alexandre Gerber 2 , Z . Morley Mao 1 , Subhabrata Sen 2 , Oliver Spatscheck 2 1 University of Michigan 2 AT&T Labs - Research. June 27 2012.

linh
Download Presentation

Web Caching on Smartphones: Ideal vs. Reality

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Caching on Smartphones: Ideal vs. Reality Feng Qian1, KeeShen Quah1, Junxian Huang1, Jeffrey Erman2 AlexandreGerber2, Z. Morley Mao1, Subhabrata Sen2, Oliver Spatscheck2 1University of Michigan 2AT&T Labs - Research June 27 2012

  2. 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 1600% increase Source: Cisco Visual Networking Index (VNI) Global Mobile Data Traffic Forecast, 2011-2016

  3. 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

  4. 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 Well known protocol for 20 years What is the state-of-the-art in the context of cellular devices? Last-Modified: Feb 1 2012 15:00:00 Expires: 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:00 Expires: Feb 15 2012 15:00:00 Last-Modified: Feb 1 15:00:00 Expires: Feb 10 15:00:00 Last-Modified: Feb 12 15:00:00 Expires: Feb 15 15:00:00

  5. 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 They account for 20% of the total HTTP traffic volume!

  6. Measurement Data User interface for the data collector/uploader software

  7. 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

  8. 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) Under-estimation due to HTTPS and app-semantic-related redundancy Client Issue Server Issue

  9. 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 MBachieves 90% of the gain (w.r.t. traffic reduction) compared to an unlimited cache It is unlikely that the handset is rebooted during such a short interval. The benefits are significant even for a small cache. Dist. of intervals between consecutive cache hits on the same entry (ISP trace)

  10. Quantifying the ResourceImpact of Redundant Traffic Compute the impact:ΔE = (E0 – ER) / E0 • In cellular networks, we also care about cellular resources • Use our trace-driven RRC state machine simulator with a handset radio power model[Qianetal, 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 ΔE: Radio energy impact of redundant transfers (a positive value) ER: Radio energy consumption in modified traces with redundant transfers removed E0: Radio energy consumption in original traces

  11. 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

  12. 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 implementation • Revisit: which factor has the main responsibility for redundancy? • Problematic caching logic • Limited cached size • Non-persistent cache

  13. 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. • PASSiff 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

  14. Test Results • 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-cacheor Cache-Control:no-cache. • … A huge gap between protocol specification and implementation, leading to significant redundancy of network traffic.

  15. Summary • The first network-wide studyof 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

  16. Backup Slides

  17. 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 tcpdumptraces • They do not cache HTTP responses • Some apps have negligible redundant transfers • Almost all bytes are not cacheablee.g., all requests are HTTP POST instead of HTTP GET

  18. The Cache Simulator (Simplified Version) • 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. Duplicated transfer: the file has not changed after the cache entry expires, but the handset does not perform cache revalidation. Cache miss. The file contains "Cache-Control: no-store“. It cannot be cached. Duplicated transfer: A request is issued before the file expires. Duplicated transfer: the file has not changed after the cache entry expires, but the server does not recognize the cache revalidation. 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.

  19. 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 Delay: 1.5s Delay: 2s Tail Time UMTS RRC State Machine for a large US 3G carrier

  20. Background: Radio Resource Management in Cellular Networks Promo Delay 2 Sec DCH Tail 5 sec FACH Tail 12 sec Tail Time Waiting inactivity timers to expire

More Related