MoBed:MoBed: A A MoMobile Test-bile Test-BedBed for Investigating Web for Investigating Web Access Solutions for J2ME-enabled devicesAccess Solutions for J2ME-enabled devices

By By

Mildred AmbeMildred Ambe

Supervisors:Supervisors:

Eleni Stroulia, Ioanis NikolaidisEleni Stroulia, Ioanis Nikolaidis

January 28, 2004January 28, 2004

Presentation OutlinePresentation Outline

Research problem Related Research Client Baseline Architecture MoBed Client-Proxy Architecture Empirical Evaluation Research contributions Future work Conclusion

The Research ProblemThe Research Problem Java II Platform, Micro Edition (J2ME)Java II Platform, Micro Edition (J2ME)

– Emerges as the standard for the fast-growing wireless Web industry– Positions itself as the best solution for an extremely wide range of devices: low-low-

end devicesend devices (pagers, PDA, etc) and high-end deviceshigh-end devices (Internet TVs, set-top boxes, etc) [LG-J2ME].

A general test-bed is required for J2MEA general test-bed is required for J2ME– Addressing low bandwidth connectivity.

– Improving performance by locally caching accessed and anticipated web-based content, for future requests.

““an intelligent ‘Client-Proxy-Server’ test-bed architecture for flexibly an intelligent ‘Client-Proxy-Server’ test-bed architecture for flexibly combining caching and prefetching schemes while separating the combining caching and prefetching schemes while separating the

mobile-resident and proxy-resident functionality”mobile-resident and proxy-resident functionality”

Related ResearchRelated Research Mobile Web Access:Mobile Web Access:

– General themes:General themes: fetch-on demand, progressive content rendering to client / display on demand, web page summarization, delivered web content in different format from original ( [CM03], [STHK03],

[BGMP00] …)

J2ME and the Web:J2ME and the Web:– J2ME and J2EE client-server applications [Hem02]J2ME and J2EE client-server applications [Hem02] – Challenges:

• Mobile applications show dependence on the network• Mobile device constraints: high latency, low bandwidth, poor connectivity.

– Using J2ME / J2EEUsing J2ME / J2EE together [SUN03]together [SUN03] – Guidelines for designing wireless clients for enterprise applications using J2ME and J2EE technology:

• Three aspects to networked wireless applications: client-side architecture, messaging and presentation.

Emulated Emulated clientclient

Client Baseline Architecture (c.)Client Baseline Architecture (c.)

J2ME Wireless J2ME Wireless ToolkitToolkit

Browser MIDletBrowser MIDlet

Connect to WWW Server

Retrieve URL

Generate User Interface

Parse the HTML data

Render parsed HTML data into displayable format

Update User Interface to display

Web page

Web ServerWeb Server

Read in Read in URL bytesURL bytes

Request (url)Request (url)

Run the Run the applicationapplication

Request Request DispatcherDispatcher

Browser MIDletBrowser MIDlet

GUI BuilderGUI Builder

Mobile ClientMobile Client

MoBed Client-Proxy ArchitectureMoBed Client-Proxy Architecture

Two main components: Mobile clientMobile client and Proxy server.Proxy server.

(a) Mobile Client:(a) Mobile Client:

J2ME Wireless J2ME Wireless ToolkitToolkit Proxy ServerProxy Server

PP

Display browser screen Display browser screen Get Get URLURL

Transcoded content bytesTranscoded content bytes

Decode & render page bytes Decode & render page bytes UI updateUI update

Request Request (URL)(URL)

Transcoded bytesTranscoded bytesEmulated Emulated

clientclient

MoBed Client-Proxy ArchitectureMoBed Client-Proxy Architecture

(b) Proxy Server:(b) Proxy Server:

Web ServerWeb ServerEmulated Emulated

clientclient

Proxy ControllerProxy Controller

HTML ParserHTML Parser

TranscoderTranscoder

Request Request (URL)(URL)

Client Client Session Session RegistryRegistry Proxy Proxy

CacheCache

Data bytesData bytes

Request (URL)Request (URL)

Retrieve URLRetrieve URL

 Open socket connection to client.Listen, retrieve client requestsInitiate Cache, Client Registry

Check Cache (URL)

Update Client

Session

Session TrackerSession Tracker

Obtain Client IP

NY

 Init Parser Connect to Web

HTMLNodes creation Collection

 Transcode HTML Nodes

Transcoded Transcoded requested requested

bytesbytes

Transcoded Transcoded requested requested

bytesbytes

Cache Cache UpdatUpdat

ee

ProxyProxy

Proxy data Proxy data compressioncompression

Caching at Caching at Proxy levelProxy level

Empirical evaluationEmpirical evaluation

MoBed ExperimentsMoBed Experiments – simulation studysimulation study used to study performance below:

ExperimentExperiment Factor (s)Factor (s) Response variable (s)Response variable (s) # Runs# Runs

11

    Proxy location

  Caching scheme   Proxy cache size

Proxy-to-Mobile response time8

22 Original number of data bytes from Web Server

Number of Proxy-Transcoded data bytes for client

N/A

333-13-1

Client cache size

% of Proxy accesses;    % of Prefetch-interrupts from large predicted files;    # files prefetched to clients;    # clients prefetched to.

51

3-23-2

-       PathTree size, vary T-value-       Using a Retraining phase-       Workload size

  % of Predicted File Hit Ratios  % of Predicted Byte Hit Ratios

Client Caching & Client Caching & Proxy PrefetchingProxy Prefetching

Experiment 1Experiment 1 Caching at Proxy level:Caching at Proxy level:

– MeasureMeasure Proxy Latency -Proxy Latency - Delays from Proxy server due to fetching (from cache/Web server) and transcoding web content

RUNS DescriptionAverage latency

1 LRU_Remote_50 23.05071

2 LRU_Remote_100 54.34064

3 LRU_WebServer_50 10.02643

4 LRU_WebServer_100 11.60464

5 LFU_Remote_50 22.16764

6 LFU_Remote_100 22.777

7 LFU_WebServer_50 12.32043

8 LFU_WebServer_100 11.41714

Observations:Observations:– Better results with LFU cache eviction– Lower avg. latency observed when Proxy server located on Web server machine

Experiment 2Experiment 2 Data compression using Proxy Transcoder:Data compression using Proxy Transcoder:

–Measure Usefulness of Transcoder as a data compressing tool

–Calculate the difference between: # bytes obtained from the Web server vs. # bytes transcoded

Original bytes fetched from WWW servers VS. bytes processed by Proxy server for Mobile client

-20000

0

20000

40000

60000

80000

100000

120000

140000

1 7 13

19

25

31

37

43

49

55

61

67

73

79

85

91

97

103

109

115

Number of URLs

Nu

mb

er

of

Byte

s

Proxy-generated bytes Original bytes from WWW

Observations:Observations:

‘Original’ data content size > 20 kBOriginal’ data content size > 20 kB transcoding proved to be more noticeable.

Smaller data content sizesSmaller data content sizes transcoded byte sizes can sometimes be larger than the original.

Encapsulation overheadEncapsulation overhead – due to the representation of transcoded content for mobile clients (e.g. use of String objects)

There is room for improvement.There is room for improvement.

Experiment 3-1Experiment 3-1 Impact of client caches:Impact of client caches:

– Measure with respect to: % requests satisfied from client caches, % prefetch-interrupts from large files, # clients serviced, # files prefetched.

Observations:Observations:– From the 2 workloads used, C301 dataset is more closely related to possible access behavior for mobile clients than CS dataset ( less dense URL structure; sparser access pattern over time).

– From 3-1, best results show 28.8%28.8% of all client requestsof all client requests were satisfied from client caches (as a result of prefetching).

– Caching results of popular accesses in addition to prefetched documents could be widely effective in reducing mobile client-perceived latency and overall proxy/server loads.

Experiment 3-2Experiment 3-2 Accuracy of the Proxy Prediction Engine:Accuracy of the Proxy Prediction Engine:

– Measure the Predicted File hit and Byte hit ratios - Prediction using Prediction using Path ProfilesPath Profiles [SKS98].– File hits = (Total # correct guess (Total # correct guess total # guesses) total # guesses)– Byte hits = (Total # correct file bytes (Total # correct file bytes total # bytes guessed) total # bytes guessed)

Observations:Observations:– Prediction algorithm evaluation:

– Inclusion of a re-training phase very slight increase in performance– Prediction accuracy decreased with increased workload size – Increasing T-value better accuracy (max. accuracy of 40.6%).

Research ContributionsResearch Contributions MoBed objective achieved:MoBed objective achieved:

– Combination of caching and prefetching schemes– Client and proxy levels allow for separation of mobile-resident from proxy-

resident functionality. Enhanced J2ME awareness:Enhanced J2ME awareness:

– J2ME: fairly new specification with rapidly growing popularity– MoBed introduces a fresh perspective on mobile web access targeting the

J2ME platform. MoBed architecture:MoBed architecture:

– Client-proxy architecture is essential for wireless web access– Caching and prefetching at proxy-level could be particularly advantageous

to J2ME devices with more than minimum CLDC/MIDP requirements.– Even though it is not yet extensible, this architecture design is clean,

configurable and modular.

Future Work Future Work

Architecture deployment:Architecture deployment:– Currently, application development has been restricted to the J2ME

Wireless toolkit.– Deployment on actual J2ME-enabled device will reveal issues/concerns

not apparent in the architecture at the moment. Improvements to some MoBed components:Improvements to some MoBed components:

– Improved HTML Parsing scheme– Data transcoding technique with reduced overhead, efficient HTML

compression– Implement an accurate model for simulating transfer delays on the mobile-

to-proxy link.– Investigate additional caching/prefetching schemes

Future Work (c.)Future Work (c.)

Building a MoBed framework:Building a MoBed framework:– Such a framework - ideal for flexiblyflexibly combining caching and prefetching

schemes for investigating Web access solutions.– Possible framework hookshooks – caching and/or prefetching extension point,

data compression/transcoding and HTML parsing extension points.– Such hooks would ensure framework adaptation by enabling/disabling,

replacing or augmenting the extensions.

Servicing multiple, diverse clients:Servicing multiple, diverse clients:– Proxy services available to J2ME clients with different device

capabilities/constraints.– ‘Discrimination’ between clients: maintain knowledge base of all clients &

their device capabilities; prefetch differently (liberal/conservative) to clients based on their capabilities.

ConclusionConclusion

Wireless devices like cell phones, pagers, etc. are increasingly used nowadays:– They provide convenient services: email, instant messaging, Internet

access, etc.– They are not restricted by place or time; easily customizable to user needs.

A lot of research has been reported on performance of Web caching/prefetching for wired Internet access; challenges arise in a wireless network.

Achieved its objective via the implementation and experimentation of Achieved its objective via the implementation and experimentation of MoBed Client-Proxy-Server architecture.MoBed Client-Proxy-Server architecture.

Results show promise Results show promise encouraging further research in this area. encouraging further research in this area.

ReferencesReferences[Hem02] - David Hemphill; J2ME and J2EE: Together – “At Last Sun has developed a blueprint for

creating mobile and wireless applications that access enterprise services—where do we go from

here?”

[SUN03] - Java Blueprints for a Wireless white paper - Designing Wireless Clients for Enterprise

Applications with Java Technology;

[CM03] - H. Chen and P. Mohapatra; A Novel Navigation and Transmission Technique for mobile

handheld devices;

[STHK03] - Bill N. Schilit, Jonathan Trevor, David M. Hilbert, and Tzu Khiau Koh; m-links: An

infrastructure for very small Internet devices;

[BGMP00] - O. Buyukkokten, H. Garcia-Molina, and A. Paepcke; Seeing the Whole in parts: Text

Summarization for Web Browsing on Handheld devices;

[HP1.1] - HTML Parser version 1.1; http://htmlparser.sourceforge.net/

[SKS98] - S.E. Schechter, M. Krishan, M.D. Smith; Using Path Profiles to Predict HTTP Requests;

Questions & AnswersQuestions & Answers