Computer Laboratory

Optimizing the Web over GPRS: Design, Implementation and Some Real Experiences

Rajiv Chakravorty

Email: rajiv.chakravorty@cl.cam.ac.uk

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

General Packet Radio Service

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

Experimental Test Set-up

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

GPRS – TCP Experience (2)

SLOW START ACK COMPRESSION

Computer Laboratory

GPRS – TCP Experience (3)

EXCESS QUEUING TCP SACKs USEFUL

Computer Laboratory

Flow fairness can be a problem over GPRS…

GPRS – TCP Experience (4)

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

How? …Use GPRSWeb

A HTTP Optimizing Proxy System

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

GPRSWeb Proxy Design

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

Experimental Test-bed Set-up

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 (1)

40-45% Reduction

55-60% Reduction

3-5% benefit

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 (3)

40-45% Reduction

45-50% Reduction

Computer Laboratory

GPRSWeb Performance (4)

50-55% Reduction

55-60% Reduction

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: Rajiv.Chakravorty@cl.cam.ac.uk