1 / 45

Computer Laboratory

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?

claire-davis
Télécharger la présentation

Computer Laboratory

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

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

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

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

  5. General Packet Radio Service

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

  7. Experimental Test Set-up

  8. GPRS – Real Experience • RTTs = uplink + downlink delays •  Typically higher than 800-1000msec

  9. GPRS – TCP Experience (1) Widely Variable BWs Sudden Fluctuations (e.g., during Mobile Assisted Cell-Updates)

  10. GPRS – TCP Experience (2) ACK COMPRESSION SLOW START

  11. GPRS – TCP Experience (3) EXCESS QUEUING TCP SACKs USEFUL

  12. GPRS – TCP Experience (4) Flow fairness can be a problem over GPRS…

  13. Latency Does Matter…

  14. A Comparison of Sample RTTs Reveals Stark Differences in GPRS & WLAN Link Characteristics

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

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

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

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

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

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

  21. How? …Use GPRSWeb A HTTP Optimizing Proxy System

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

  23. GPRSWeb Proxy Design

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

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

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

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

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

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

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

  31. Experimental Test-bed Set-up

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

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

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

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

  36. GPRSWeb Performance (1) 3-5% benefit 40-45% Reduction 55-60% Reduction

  37. GPRSWeb Performance (2) 3-5% benefit 25-30% Reduction 35-40% Reduction Not much extra benefit out of image trans-coding (only 2-5%)

  38. GPRSWeb Performance (3) 40-45% Reduction 45-50% Reduction

  39. GPRSWeb Performance (4) 50-55% Reduction 55-60% Reduction

  40. GPRSWeb Performance (5) 25-30% Benefit 35-40% Reduction Image trans-coding shows no benefit

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

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

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

  44. Concluding Remarks • Proxy-Assisted Adaptation seems a Promising Approach for Improving Application and Protocol Performance over Wide Area Wireless

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

More Related