CSE 535 – Mobile Computing Lecture 8: Data Dissemination Sandeep K. S. Gupta School of Computing and Informatics Arizona State University

Data Dissemination

Communications Asymmetry Network asymmetry In many cases, downlink bandwidth far exceeds uplink bandwidth Client-to-server ratio Large client population, few servers Data volume Small requests for info, large responses Again, downlink bandwidth more important Update-oriented communication Updates likely affect a number of clients

Disseminating Data to Wireless Hosts Broadcast-oriented dissemination makes sense for many applications Can be one-way or with feedback Sports Stock prices New software releases (e.g., Netscape) Chess matches Music Election Coverage Weather…

Dissemination: Pull Pull-oriented dissemination can run into trouble when demand is extremely high Web servers crash Bandwidth is exhausted client server hel p

Dissemination: Push Server pushes data to clients No need to ask for data Ideal for broadcast-based media (wireless) client server Whew !

Broadcast Disks server Schedule of data blocks to be transmitted

Broadcast Disks: Scheduling Round Robin Schedule Priority Schedule

Priority Scheduling (2) Random Randomize broadcast schedule Broadcast "hotter" items more frequently Periodic Create a schedule that broadcasts hotter items more frequently… …but schedule is fixed "Broadcast Disks: Data Management…" paper uses this approach Simplifying assumptions  Data is read-only  Schedule is computed and doesn't change…  Means access patterns are assumed the same Allows mobile hosts to sleep…

"Broadcast Disks: Data Management…" Order pages from "hottest" to coldest Partition into ranges ("disks")—pages in a range have similar access probabilities Choose broadcast frequency for each "disk" Split each disk into "chunks" maxchunks = LCM(relative frequencies) numchunks(J) = maxchunks / relativefreq(J) Broadcast program is then: for I = 0 to maxchunks - 1 for J = 1 to numdisks Broadcast( C(J, I mod numchunks(J) )

Sample Schedule, From Paper Relative frequencies 4 2 1

Broadcast Disks: Research Questions From Vaidya: How to determine the demand for various information items? Given demand information, how to schedule broadcast? What happens if there are transmission errors? How should clients cache information?  User might want data item immediately after transmission…

Hot For You Ain't Hot for Me Hottest data items are not necessarily the ones most frequently accessed by a particular client Access patterns may have changed Higher priority may be given to other clients Might be the only client that considers this data important… Thus: need to consider not only probability of access (standard caching), but also broadcast frequency A bug in the soup: Hot items are more likely to be cached! (Reduce their frequency?)

Broadcast Disks Paper: Caching Under traditional caching schemes, usually want to cache "hottest" data What to cache with broadcast disks? Hottest? Probably not—that data will come around soon! Coldest? Ummmm…not necessarily… Cache data with access probability significantly higher than broadcast frequency

Caching, Cont. PIX algorithm (Acharya) Eject the page from local cache with the smallest value of: probability of access broadcast frequency Means that pages that are more frequently accessed may be ejected if they are expected to be broadcast frequently…

Broadcast Disks: Issues User profiles Provide information about data needs of particular clients "Back channel" for clients to inform server of needs Either advise server of data needs… …or provide "relevance feedback" Dynamic broadcast Changing data values introduces interesting consistency issues If processes read values at different times, are the values the same? Simply guarantee that data items within a particular broadcast period are identical?

Hybrid Push/Pull "Balancing Push and Pull for Data Broadcast" (Acharya, et al SIGMOD '97) "Pull Bandwidth" (PullBW) – portion of bandwidth dedicated to pull-oriented requests from clients PullBW = 0% "pure" Push Clients needing a page simply wait PullBW = 100% Schedule is totally request-based

Interleaved Push and Pull (IPP) Mixes push and pull Allows client to send requests to the server for missed (or absent) data items Broadcast disk transmits program plus requested data items (interleaved) Fixed threshold ThresPerc to limit use of the back channel by a particular client Sends a pull request for p only if # of slots before p will be broadcast is greater than ThresPerc ThresPerc is a percentage of the cycle length Also controls server load–as ThresPerc  100%, server is protected

CSIM-based Simulation Measured Client (MC) Client whose performance is being measured Virtual Client (VC) Models the "rest" of the clients as a single entity… …chewing up bandwidth, making requests… Assumptions: Front channel and back channel are independent Broadcast program is static—no dynamic profiles Data is read only

Simulation (1) No feedback to clients!

Simulation (2) Can control ratio of VC to MC requests Noise controls the similarity of the access patterns of VC and MC Noise == 0  same access pattern PIX algorithm is used to manage client cache VC's access pattern is used to generate the broadcast (since VC represents a large population of clients) Goal of simulation is to measure tradeoffs between push and pull under broadcast

Simulation (3) CacheSize pages are maintained in a local cache SteadyStatePerc models the # of clients in the VC population that have “filled” caches—e.g., most important pages are in cache ThinkTimeRatio models intensity of VC request generation relative to MC ThinkTimeRatio high means more activity on the part of virtual clients

Simulation (4)

Experiment 1: Push vs. Pull Important! PullBW set at 50% in 3a – if server's pull queue fills, requests are dropped! At PullBW = 10%, reduction in bandwidth hurts push, is insufficient for pull requests! server death! Light loads: pull better

Experiment 2: Cache Warmup Time for MC Low server load: pull better. High server load: push better.

Experiment 3: Noise: Are you (VC) like me (MC)? On the left, pure push vs. pure pull. On the right, pure push vs. IPP !!!

Experiment 4: Limiting Greed If there’s plenty of bandwidth, limiting greed isn’t a good idea On the other hand…

Experiment 5: Incomplete Broadcasts Not all pages broadcast—non-broadcast pages must be explicitly pulled Lesson: Must provide adequate bandwidth or response time will suffer! In 7b, making clients wait longer before requesting helps… Server overwhelmed—requests are being dropped!

Incomplete Broadcast: More Lesson: Careful! At high server loads with lots of pages not broadcast, IPP can be worse than push or pull!

Experimental Conclusions Light server load: pull better Push provides a safety cushion in case a pull request is dropped, but only if all pages are broadcast Limits on pull provide a safety cushion that prevents the server from being crushed Broadcasting all pages can be wasteful But must provide adequate bandwidth to pull omitted pages… Otherwise, at high load, IPP can be worse than pull! Overall: Push and pull tend to beat IPP in certain circumstances But IPP tends to have reasonable performance over a wide variety of system loads… Punchline: IPP a good compromise in a wide range of circumstances

Mobile Caching: General Issues Mobile user/application issues: Data access pattern (reads? writes?) Data update rate Communication/access cost Mobility pattern of the client Connectivity characteristics  disconnection frequency  available bandwidth Data freshness requirements of the user Context dependence of the information

Mobile Caching (2) Research questions: How can client-side latency be reduced? How can consistency be maintained among all caches and the server(s)? How can we ensure high data availability in the presence of frequent disconnections? How can we achieve high energy/bandwidth efficiency? How to determine the cost of a cache miss and how to incorporate this cost in the cache management scheme? How to manage location-dependent data in the cache? How to enable cooperation between multiple peer caches?

Mobile Caching (3) Cache organization issues: Where do we cache? (client? proxy? service?) How many levels of caching do we use (in the case of hierarchical caching architectures)? What do we cache (i.e., when do we cache a data item and for how long)? How do we invalidate cached items? Who is responsible for invalidations? What is the granularity at which the invalidation is done? What data currency guarantees can the system provide to users? What are the (real $$$) costs involved? How do we charge users? What is the effect on query delay (response time) and system throughput (query completion rate)?

Weak vs. Strong Consistency Strong consistency Value read is most current value in system Invalidation on each write can expire outdated values Disconnections may cause loss of invalidation messages Can also poll on every access Impossible to poll if disconnected! Weak consistency Value read may be “somewhat” out of date TTL (time to live) associated with each value Can combine TTL with polling e.g., Background polling to update TTL or retrieval of new copy of data item if out of date

Disconnected Operation Disconnected operation is very desirable for mobile units Idea: Attempt to cache/hoard data so that when disconnections occur, work (or play) can continue Major issues: What data items (files) do we hoard? When and how often do we perform hoarding? How do we deal with cache misses? How do we reconcile the cached version of the data item with the version at the server?

One Slide Case Study: Coda Coda: file system developed at CMU that supports disconnected operation Cache/hoard files and resolve needed updates upon reconnection Replicate servers to improve availability What data items (files) do we hoard? User selects and prioritizes Hoard walking ensures that cache contains the “most important” stuff When and how often do we perform hoarding? Often, when connected

Coda (2) (OK, two slides) How do we deal with cache misses? If disconnected, cannot How do we reconcile the cached version of the data item with the version at the server? When connection is possible, can check before updating When disconnected, use local copies Upon reconnection, resolve updates If there are hard conflicts, user must intervene (e.g., it’s manual— requires a human brain) Coda reduces the cost of checking items for consistency by grouping them into volumes If a file within one of these groups is modified, then the volume is marked modified and individual files within can be checked

WebExpress Housel, B. C., Samaras, G., and Lindquist, D. B., “WebExpress: A Client/Intercept Based System for Optimizing Web Browsing in a Wireless Environment,” Mobile Networks and Applications 3:419–431, System which intercepts web browsing, providing sophisticated caching and bandwidth saving optimizations for web activity in mobile environments Major issues: Disconnected operation Verbosity of HTTP protocol  Perform Protocol Reduction TCP connection setup time  Try to re-use TCP connections Low bandwidth in wireless networks  Caching Many responses from web servers are very similar to those seen previously  Use differencing rather than returning complete responses, particularly for CGI-based interactions

WebExpress (2) Two intercepts: both on client side and in the wired network Caching on both client and on wired network + differencing One TCP connection Reduce redundant HTTP header info Reinsert removed HTTP header info on server side