[ Home | Class Roster | Syllabus | Status | Glossary | Search | Course Notes]
from this paper
problem: access to information sources while away from desktop.
caravan model: carry feature-impaired portable access device (PDA, laptop).
hotel model: travel lightly, get access using "borrowed" equipment (VNC)
piggyback dual use model: overload information services onto ubiquitous cell phone
SMS (Short Message Service):
GSM standard
160 character messages
store and forward
Each service requires a "handler"
Examples
share price
weather
active badge handler
train
currency
road/traffic
Push/Pull services
PUSH: uses "cron" checks net - forwards items that meet criteria
Prevent bugs from inadvertently using expensive service
Use message counter per day
Use phone number for user id
normal and special messages
special allow reset of quotas
Denial of service: (global safeguard)
build own CGI scripts
use someone else's phone
download, customized features into phone.
Can change menus on Nokia phone
fuse information
from this paper
GRAND CHALLENGE: using behavior (semantics?) to improve performance.
Study of potential for pre-fetch to low bandwidth clients.
browser with large cache (4%)
delta compression (+14.6%)
proxy server (to which low-bandwidth client is attached)
Prediction-by Partial Matching (PPM) (+28.6%)
Examples of anticiparallelism;
Assumptions:
idle time between requests (e.g. while user reads latest document)
Proxy can predict near future access based on past behavior
proxy holds recently accessed pages
only pre-fetch pages already in proxy cache
Request results in the following three cases:
In browser cache (communicate hit to proxy?)
being prefetched
needs to be fetched by proxy
browser cache hit ratio
cached due to previous hit
pre-fetched and cached
partially pre-fetched
latency reduction
wasted bandwidth due to pre-fetch
not a major concern
Use HTTP traces from Berkley home dial-up connections
do not have the original browser cache hit ratio
assume 16Gb proxy cache (at this size no replacement needed)
delta compression: difference between old and updated page. (estimate 88% elimination of bytes on modified pages)
Apply application level compression to HTML (25%
reduction)
THIS IS QUESTIONABLE ALSO DUE TO UNMEASURED EFFECT OF MODEM
COMPRESSION
prefetching (assuming perfect) and delta compression biggest impacts
browser cache size only 10% hit resulting in 4.1%
reduction in latency
THIS SEEMS QUESTIONABLE IN LIGHT OF LACK OF INFORMATION ON REAL
CACHE HIT RATES
Objects accessed only once tend to be bigger than
repeatedly accessed objects (is this users avoiding pain?
20kb vs 5 kb
plenty of idle time to prefetch
hit ratio in proxy cache is 58.6%
limited by restriction to prefetching only from proxy cache
| Browser Cache | Delta | HTML Comp | Prefetch | Request savings | Latency reduction |
| Infinite | No | No | No | 10% | 4% |
| Infinite | Yes | No | No | 24% | 15% |
| Infinite | Yes | No | Perfect | 50% | 29% |
| 2MB | Yes | No | No | 21% | 13% |
| 16MB | Yes | No | No | 23% | 14% |
| 16MB | Yes | No | Perfect | 50% | 28% |
| No cache | No | Yes | No | 0% | 2% |
| 16Mb | Yes | Yes | No | 23% | 17% |
| 16Mb | Yes | Yes | Perfect | 50% | 30% |
Comments:
Use all user's behavior in prediction process (less specific but larger sample size)
Model history as a forest of trees:
Each accessed page is the root of a tree
probability of access is estimated from past history
next level is all pages accessed from the root and their estimated probabilities
continue down levels in similar fashion.
probability estimate modeled as count of number of accesses
for nodes below root, probability is path based (i.e. probability that this node is accessed in this sequence.)
In order to represent this model, the following parameters are defined
prefix depth (m): the number of past accesses used to predict future ones
search depth (l): number of future accesses to predict
threshold (t): probability threshold
history structure keeps all trees of depth K = m + l.
looking at last "m" accesses by user, find tree which matches this sequence (or any subsequence)
list the next "l" accesses, adding access counts for repeats
divide by count of the sequence, yielding relative probability (why relative)
delete those with probability less than "t"
sort list based on probability
when modem idle, starts pre-fetch using this list
Other constraints, less than 50kb and no more than 8 object pre-fetch (we are competing with browser cache)
prefetching reduced latency between 17-23%
request saving (hit ratio) ranged from 27-39%
extra traffic 1-15%
hits 60% normal caching 40% prefetch
increased search depth (l) improves performance (l=4
is good)
range 17(1)-21(8)
Increasing prefix depth(m) also improves performance
range 19(1)-22(2) at high threshold(.5), same at low
accuracy (percent of prefetched used) ranged from 40(2,4,.125)-73(1,1,.5)%
seems to be potential for increased prefetching which was limited by lack of idle time on modem and limit of 8 prefetch objects
large number of image files - suggests search for embedded objects
46-50% prefetech are "gif", 18-24% "jpg" only 13-18% are html
compared to perfect (27% improvement) got 14%
only 22% of access pairs are repeated
See figures in paper
for this paper.
Describes adaptive middleware proxy (AMWP) supports
Transformation
Aggregation
Caching
Customization
of internet content
Claims:
better performance than client based reduced port browser
Supports new features and behaviors (beyond standard browser ones)
handles larger subset of existing internet content transparently
cost effective and scalable
TACC workers
image processor
converts to scaled, color mapped bitmaps
HTML processor
maps to reduced font tags
lay out proceeds in parallel to inline image conversion
page sent as one object
zip processor
aggregator request service
proxy can be more robust than client
faster than netscape
lots of bad HTML
new data types (aportisDoc type)
whiteboard