Enhanced Services for WWW in Mobile WAN Environment

Mika Liljeberg, Heikki Helin, Markku Kojo, Kimmo Raatikainen, Univ. of Helsinki (MOWGLI)

One-line abstract: More fleshed-out implementation of Pythia, but adding a client-side agent to do various optimizations and focusing on GSM exclusively (no adaptation, no "smart" compression). This paper seems to supersede "Optimizing WWW For Weakly-Connected Mobile Workstations: An Indirect Approach"; the work here seems more complete.

Main points:

Factoid: GSM roundtrip abou;t 1 sec; nominal bandwidth 9600 baud.
Mowgli goals:
- Discourage burstiness (low utilization)
- Minimize data transfer to MH
- Disconnected operation
- Compatibility w/existing SW
- Fine-grain user control over wireless link use
Client-side "agent" acts as local HTTP proxy; communicates with its evil twin at MCH over MDCS (Mowgli Data Channel Service) instead of TCP, and using MHTTP (Mowgli-HTTP; basically tokenized HTTP) instead of regular HTTP.
MDCS: session-oriented delivery service that provides either reliable streams or datagrams, with pre-emptive priorities. Creating new logical connections is very lightweight. Sounds like what we need!
Proxy does GIF-to-JPEG translation; prefetching of first-level links; enforces max. size for text and images; annotates URL's to indicate which ones are in (agent-controlled) client side cache; supports a background transfer queue with user interface. UI is provided mostly in HTML, by the client-side agent; some parts provided by a "control panel" that runs alongside browser and communicates w/evil twin. See picture on p.7 of paper.
Disconnected operation: session state is maintained at the MDCS level! So application doesn't really know what's happened.
Performance: about 50% latency reduction compared to standard setup; improvement is reduced as more images are added, probably because they don't do significant image compression, which is where the big wins are.

Flaws/comments:

No adaptation to network link, except for disconnection support
No "smart compression": generally lossless compression which is decompressed at the agent.
The approach of a client-side agent is fine for Unix, but may be difficult for other platforms, which is why I've decided to move the HTTP protocol filter exclusively to the proxy side.
They don't seem to indicate that a proxy is not just for compatibility with current apps--it is a key part of the picture even with future mobile-aware apps.

Back to index