450 likes | 593 Views
Optimizing the Web over GPRS: Design, Implementation and Some Real Experiences Rajiv Chakravorty Email: rajiv.chakravorty@cl.cam.ac.uk. With Andrew Clark and Dr. Ian Pratt. Computer Laboratory. What this talk is all about. What are the “typical” GPRS network characteristics?
E N D
Optimizing the Web over GPRS: Design, Implementation and Some Real ExperiencesRajiv ChakravortyEmail: rajiv.chakravorty@cl.cam.ac.uk With Andrew Clark and Dr. Ian Pratt Computer Laboratory
What this talk is all about • What are the “typical” GPRS network characteristics? • What are the practical performance problems using TCP and HTTP over GPRS? • What overall benefits can we achieve using various application levels optimisations over GPRS?
Brief Outline of my Talk • Wide Area Wireless • The GPRS Experience • GPRSWeb Proxy System • Motivation • Design and Implementation • Test Deployment, and Real Test-Bed Experiences
Wide Area Wireless Networks • GSM 9.6 kbps • CDPD 19.2 kbps • Metricom Ricochet 29-32Kb/s • CDMA (IS-95B) upto 64 kbps • GPRS 171.2 kbps (in theory!) • WCDMA/CDMA 2000 2Mbps 2G 2.5G 3G
GPRS – In One Slide • A GSM Overlay for higher data rates • “Always ON” service • Radio Resources on Demand • Support for Interactive traffic (Web) • Radio Resources shared (GSM –GPRS) • Network Operators give strict priority to voice traffic (GSM). • Time-slots (PDCHs) are generally dynamically allocated. • Reliable in-order delivery • RLC (radio link control) uses reliable mode.
GPRS – Real Experience • RTTs = uplink + downlink delays • Typically higher than 800-1000msec
GPRS – TCP Experience (1) Widely Variable BWs Sudden Fluctuations (e.g., during Mobile Assisted Cell-Updates)
GPRS – TCP Experience (2) ACK COMPRESSION SLOW START
GPRS – TCP Experience (3) EXCESS QUEUING TCP SACKs USEFUL
GPRS – TCP Experience (4) Flow fairness can be a problem over GPRS…
A Comparison of Sample RTTs Reveals Stark Differences in GPRS & WLAN Link Characteristics
GPRS “behavior”: Summary • RTTs: 800ms-1000ms or more • Bandwidths: Variable and sometimes Fluctuating • Packet Losses: Typically follow link outages (burst losses …) • ACK Compression • Link Outages (Blackout time) ~ 4-40s.
TCP Problems over GPRS • Slow start gets ReallyS L O W … • Excessive Queuing at CGSN Node • Flow Unfairness in TCP • Sluggish Recovery Poor Utilization • Read Ahead: [IEEE GLOBECOM’02]
Web Performance over GPRS • Many Web browsers aggressive • Control/Connection Set-up Overhead • Saturation of Downlink Buffers • HTTP/1.0, HTTP/1.1 – inefficient • What about Pipelining? [IEEE MWCN’02]
Improving Performance For Web browsing, file downloads, reading e-mails, instant messaging, news etc. Specifically, we concentrate on Web Performance, where majority of connections are shipped in the downlink direction
Improve How? • Using PERFORMANCE PROXIES • Two Cases: • Change ‘staple’ Internet Protocols • Why not TCP? (Transparent TCP Proxies) • Simply Adapt and Optimise [INFOCOM’03] • Change WAP style. • Re-Invent Transport for GPRS • Added Optimisations [Mobisys’03]
Change WAP style? • ReplaceTCP • TCP performance over GPRS miserable … • Use Custom Protocol – UDP based • Modify HTTP for GPRS • Added Optimisations over GPRS • Of course Requires Client-Side Software Updates …
How? …Use GPRSWeb A HTTP Optimizing Proxy System
GPRSWeb Proxy System • A Dual-Proxy Architecture, for webOptimisation over GPRS • ‘Client’ Proxy and ‘Server’ Proxy together Squeeze the Web for GPRS • Several Enhancements: Caching, Pre-emptive Data push, Client-specific Resource Adaptation, Delta-encoded data Transfers, DNS Look-ups Migration, etc….
GPRSWeb: Key Features • A New GPRSWeb TransportProtocol • UDP based • Extended Caching • Use Client-Proxy and Server-Proxy Cache – Eliminate those extra RTTs • Data Compression and Delta Encoding • Reduced transfer Size and time • Parse-and-Push • Pro-actively push objects to the Client
GPRSWeb Transport Protocol • UDP-based • Selective Repeat based on NACKs • No SLOW-START, instead TCP Clamp • No Congestion Control over GPRS • Implements Ordered-Reliable Message Transfer • Connection Set-up like T/TCP. • Minimizes Link Traversals • Responds Efficiently during Packet Loss Epoch • Achieves substantially better link utilization than TCP
Extended Caching(1) • Extended Client-Side Caching • Optimise hit-rates of client cache • Browser Cache disabled and flushed • Index Objects by their SHA-1 fingerprints (content hash keys) • A separate table maps URL-CHKs • Multiple duplicates stored only once • Identical mappings commonplace, this gives high hit rates (e.g. BBC Web-site)
Extended Caching(2) • Client Cache freshness scheme can be configured to return potentially stale data to allow something for display during link outages • The Server proxy keeps track of each of the client proxy’s cache by modeling the replacement policy, which is currently “least recently used” eviction
Compression/Delta-Encoding • Ensures data travelling over the GPRS link is compressed • Don’t Compress Compressed (e.g. JPEGs, Zip Archives) • Updates sent typically as Deltas • Successful in most cases where updates are similar to predecessor (e.g. pages with time-of-day strings) • Re-Generate HTTP headers using a separate string table. (as browser generated headers rather verbose)
Parse-n-Push • Most web pages contain a number of images and objects • So why not Speculatively Push Objects towards the client cache • Sent typically as low priority • Parsing crude, fast extraction of references using a regular expression • Duplicates are removed, and relative URLs combined
DNS Look-ups Migration • DNS look-up over GPRS would entail one additional RTT • Why not let the Proxy Server do the look-up? • So in HTTP requests, client proxy would also send the full URL string.
GPRSWeb Implementation • We have implemented GPRSWeb over Window XP/2000 • The GPRSWeb Client and Server Proxy written in C# (Csharp) over Microsoft’s .NET Framework • Uses .NET’s Powerful Function library for speeding up project development. • Client and Server Proxy Share much of the Source Code for Protocol and Cache Functionality
Test Web Sites • We hosted test web-sites in a local server, to avoid performance vagaries of the public Internet • We used two synthetic web sites and three real web sites. • Real Web-Sites all “Mocked-up” • Real web-sites (all have > 50 objects): • E-commerce • AMAZON [http://www.amazon.com] • News • BBC [http://www.bbc.co.uk] • CNN [http://www.cnn.com]
Performance Evaluation(1) • Mozilla Browser 1.0 used in tests • Instrumented to log download times • Evaluation Scenarios: • http-1.0:- Brower in non-persistent mode • http-1.1:- Browser in persistent mode • gprsweb-1:- Cold Client and Server Cache with Image Trans-coding disabled • gprsweb-2:- Same as gprsweb-1. But with a Hot server-side proxy cache • gprsweb-21:- Same as gprsweb-2. But with Image Trans-coding Enabled • gprsweb-3:- A HOT client Proxy cache. Represents Best case scenario
Performance Evaluation(2) • We use Default setting for GPRSWeb: GPRSWeb protocol, data compression, delta encoding and parse-and-push • Image Trans-coding • Currently Degrades only JPEG Images • We used a small value of 10% • We averaged download times from over 30 successful runs. For clarity, we also plot min/max and median from each data-set.
GPRSWeb Performance (1) 3-5% benefit 40-45% Reduction 55-60% Reduction
GPRSWeb Performance (2) 3-5% benefit 25-30% Reduction 35-40% Reduction Not much extra benefit out of image trans-coding (only 2-5%)
GPRSWeb Performance (3) 40-45% Reduction 45-50% Reduction
GPRSWeb Performance (4) 50-55% Reduction 55-60% Reduction
GPRSWeb Performance (5) 25-30% Benefit 35-40% Reduction Image trans-coding shows no benefit
Remarks on Performance • Depending on the web-page, GPRSWeb can lead to SubstantialReductions in page download times. • Image Trans-coding shows little benefit. Perhaps, degrading GIFs and PNGs might be a good option with more aggressive Quality Reduction Settings
Current Limitations • Scalability – We have used the proxy system only with limited set of clients. • Scalability tests of how the proxy scales to larger client base could be interesting • Security – GPRSWeb does not offer any additional authentication or encryption mechanisms • WAP based WTLS can be useful.
On-going Work • Campus WideGPRSWeb Client Software Distribution and traffic Trace Collection. • We are recording full tcpdump traces of our user community. • This will assist in Evaluating Scalability and Resulting User Experience • Thorough Evaluation of CHK-based caching and Delta-Encoding Schemes for Dynamic Content
Concluding Remarks • Proxy-Assisted Adaptation seems a Promising Approach for Improving Application and Protocol Performance over Wide Area Wireless
Download • GPRSWeb Source Code, Test Web Sites, along with other Papers and Source Codes now available: http://www.cl.cam.ac.uk/~rc277/ Any Questions Contact: Rajiv Chakravorty Systems Research Group, University of Cambridge Computer Laboratory Email: Rajiv.Chakravorty@cl.cam.ac.uk