computer laboratory optimizing the web over gprs: design, implementation and some real experiences...
Post on 19-Dec-2015
214 views
TRANSCRIPT
Computer Laboratory
Optimizing the Web over GPRS: Design, Implementation and Some Real Experiences
Rajiv Chakravorty
Email: [email protected]
Computer LaboratoryWith 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?
Computer Laboratory
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
Computer Laboratory
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
Computer Laboratory
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.
Computer Laboratory
RTTs = uplink + downlink delays
Typically higher than 800-1000msec
GPRS – Real Experience
Computer Laboratory
GPRS – TCP Experience (1)
Widely Variable BWs
Sudden Fluctuations
(e.g., during Mobile Assisted Cell-Updates)
Computer Laboratory
Latency Does Matter…
Access network Bandwidth RTT BBC News
Ethernet 10000kb/s <5ms 3s
Cable / ADSL ~512kb/s 10-50ms 6s
WLAN 802.11b ~11000kb/s 10-100ms 12s
Dialup modem ~50kb/s 140ms 22s
GSM ~10kb/s 540ms 95s
GPRS (4+1) ~45kb/s 800-1400ms
105s
Computer Laboratory
A Comparison of Sample RTTs
Reveals Stark Differences in GPRS & WLAN Link Characteristics
Computer Laboratory
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.
Computer Laboratory
TCP Problems over GPRS
Slow start gets Really S L O W …
Excessive Queuing at CGSN Node
Flow Unfairness in TCP
Sluggish Recovery Poor Utilization
Read Ahead: [IEEE GLOBECOM’02]
Computer Laboratory
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]
Computer Laboratory
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
Improving Performance
Computer Laboratory
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]
Computer Laboratory
Change WAP style?
Replace TCP 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 …
Computer Laboratory
GPRSWeb Proxy System A Dual-Proxy Architecture, for web
Optimisation 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….
Computer Laboratory
A New GPRSWeb Transport Protocol 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: Key Features
Computer Laboratory
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
Computer Laboratory
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)
Computer Laboratory
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
Computer Laboratory
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)
Computer Laboratory
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
Computer Laboratory
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.
Computer Laboratory
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
Computer Laboratory
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]
Computer Laboratory
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
Computer Laboratory
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.
Computer Laboratory
GPRSWeb Performance (2)
25-30% Reduction
35-40% Reduction
3-5% benefit
Not much extra benefit out of image trans-coding (only 2-5%)
Computer Laboratory
GPRSWeb Performance (5)
35-40% Reduction
25-30% Benefit
Image trans-coding shows no benefit
Computer Laboratory
Remarks on Performance
Depending on the web-page, GPRSWeb can lead to Substantial Reductions 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
Computer Laboratory
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.
Computer Laboratory
On-going Work Campus Wide GPRSWeb 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
Computer Laboratory
Concluding Remarks
Proxy-Assisted Adaptation seems a Promising Approach for Improving Application and Protocol Performance over Wide Area Wireless
Computer Laboratory
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 ChakravortySystems Research Group,University of Cambridge Computer
LaboratoryEmail: [email protected]