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.
- 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
- 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.
- 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
Back to index