1. 1 Lecture 2: Service and Data Management Ing-Ray Chen CS 6204 Mobile Computing Virginia Tech Fall 2005 Courtesy of G.G. Richard III for providing some of the slides for this chapter

2. 2 Service Management in PCN Systems Managing services in mobile environments How does the server find new VLR? Too much overhead in contacting HLR VLR Server

3. 3 PCN Systems: Proxy-Based Solution Per-User Service Proxy Proxy Client Server

4. 4 Per-User Service Proxy Service Proxy –Maintains service context Information –Forwards client requests to servers –Forwards server replies to clients –Tracks the location of the MU, thereby reducing communication costs

5. 5 Static Service Proxy Proxy is located at a fixed location Inefficient data route delivery Proxy Client Server

6. 6 Mobile Service Proxy Proxy could move with the client if necessary Proxy informs servers of location changes Server Proxy/ Client Proxy/ Client Proxy/ Client

7. 7 Location/Service Management Decoupled Model Traditionally, service and location management are decoupled Problem: Extra communication cost incurred for updating service proxy HLR / VLR Client Proxy

8. 8 Integrated Location and Service Management “Per-user” based proxy services Service proxy co-locates (and moves) with the MU’s location database Four possible schemes: –Centralized, fully distributed, dynamic anchor and static anchor schemes

9. 9 Integrated: Centralized Scheme The proxy is centralized and co- located with the HLR to minimize communication costs with HLR to track MU When MU moves to a different VLR, a location update operation incurs to the HLR/proxy Data delivery/call incurs a search operation at the HLR/proxy to locate the MU Data service route: Server -> proxy/HLR -> MU

10. 10 Integrated: Fully Distributed Scheme Location and service handoffs occur when MU moves to a new VLR Service proxy co-locates (moves) with the location database at the current VLR The proxy’s moving to new VLR causes a location update to the HLR/server, and a context transfer A call requires a search operation at the HLR to locate the MU Data service route: Server -> proxy/MU

11. 11 Integrated: Static Anchor Scheme VLRs are grouped into anchor areas HLR points to the current anchor Proxy is co-located with anchor in a fixed location until MU moves to anchor area Intra-anchor movement –Anchor/proxy is not moved and location update is sent to the anchor without updating the HLR Inter-anchor movement –Anchor/proxy is moved with a context transfer cost and location update is send to the HLR/servers Data/Call delivery performs a search at the HLR to locate the current anchor and then MU Service route: Server->proxy/anchor -> MU

12. 12 Integrated: Dynamic Anchor Scheme Same as static anchor except that the anchor/proxy moves to the current VLR when there is a call delivery On a call delivery –A search to the HLR is performed –If the anchor is not the current serving VLR Move anchor/proxy; information HLR/server of address change; and perform context transfer Service route: server->proxy/anchor- >MU Advantageous than static anchor when CMR and SMR are high

13. 13 Model Parameters λthe average rate at which the MU is being called. σthe average rate at which the MU moves across VLR boundaries. γthe average rate at which the MU requests services. CMRcall to mobility ratio, e.g., λ / σ. SMRservice request to mobility ratio, e.g., γ / σ. Tthe average round trip communication cost between a VLR and the HLR (or between a VLR and the server) per message. 11 the average round trip communication cost between the anchor and a VLR in an anchor area per message. 22 the average round trip communication cost between two neighboring VLRs in an anchor areas per message. 33 the average round trip communication cost between two neighboring VLRs per message. M cs the number of packets required to transfer the service context. NsNs the number of server applications concurrently engaged by the MU. P InA the probability that a MU moves within the same anchor area when a VLR boundary crossing movement occurs. P OutA the probability that a MU moves out of the current anchor area when a VLR

14. 14 Cost Model Performance metric – total communication cost per time unit: 3 basic operations –Location update ( ) – cost for updating the location of MU and service proxy (sometimes, service context transfer) –Call delivery ( ) – cost for locating a MU to deliver a call –Data service requests ( ) – cost for MU to communicate with server through proxy

15. 15 Costs for Centralized and Fully Distributed Schemes Scheme/Cost Location updateCall deliveryService request Centralized Cost to inform the location database at the HLR of the new VLR Cost to locate the MU and deliver the call from the HLR to VLR Round trip cost from MU to proxy and from proxy to server Distributed :cost to inform the HLR of the new VLR :cost to transfer service context between two neighboring VLRs for the proxy move :cost to update Ns application servers with new location of MU Cost to locate the MU and deliver the call Cost from the service proxy co- located at the current VLR to the server

16. 16 Performance Evaluation-Results Cost rate under different CMR and SMR values

17. 17 Performance Evaluation-Results Mobility rate fixed at 10 changes /hour; SMR = 1 to study the effect of varying CMR Low CMR – Static/Dynamic Anchor perform better than centralized and fully distributed High CMR – Centralized is the best. Dynamic anchor is better than static anchor. The reason is that dynamic anchor updates the HLR and moves the anchor to the current VLR, thereby reducing service request costs and location update costs Cost rate under different CMR values

18. 18 Performance Evaluation-Results Mobility rate is fixed at 10 changes/hour CMR = 1 to study the effect of SMR on cost rate Low SMR – Fully distributed scheme is the worst due to frequent movement of service proxy with mobility High SMR – Fully distributed scheme performs the best since the service proxy is co-located with the current VLR to lower the triangular cost Cost rate under different SMR values

19. 19 Performance Evaluation – Results Comparison of integrated with decoupled scheme Depending on the user’s SMR the “best” integrated scheme and decoupled scheme were compared Integrated scheme converges with the decoupled scheme at high SMR where the “influence” of mobility is less Integrated scheme is better than the basic scheme at high SMR due to triangular cost between the server and MU via HLR

20. 20 Integrated Location and Service Management in PCS: Conclusions Design Concept: Position the service proxy along with the location database of the MU Centralized scheme: Suited for low SMR and high CMR Distributed scheme: Best at high SMR and high CMR Dynamic anchor scheme: Works best for a wide range of CMR and SMR values except when service context transfer costs are high Static anchor scheme: Works reasonably well for a wide range of CMR and SMR values The best location/service integrated scheme always outperforms the best decoupled scheme, and the basic scheme

21. 21 Communications Asymmetry in Mobile Wireless Environments Network asymmetry –In many cases, downlink bandwidth far exceeds uplink bandwidth Client-to-server ratio –Large client population, but few servers Data volume –Small requests, large responses –Downlink bandwidth more important Update-oriented communication –Updates likely affect a number of clients

22. 22 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/traffic …

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

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

25. 25 Broadcast Disks 1 23 4 56 server Schedule of data blocks to be transmitted

26. 26 Broadcast Disks: Scheduling 1 23 4 56 Round Robin Schedule 1 12 1 31 Priority Schedule

27. 27 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…

28. 28 "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) )

29. 29 Sample Schedule, From Paper Relative frequencies 4 2 1

30. 30 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 Observation: Hot items are more likely to be cached!

31. 31 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

32. 32 Caching 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…

33. 33 Hybrid Push/Pull Balancing Push and Pull for Data Broadcast B = B 0 + B b –B 0 is bandwidth dedicated to on-demand pull-oriented requests from clients –B b is bandwidth allocated to broadcast B 0 = 0% "pure" Push Clients needing a page simply wait B 0 =100% Schedule is totally request-based

34. 34 Optimal Bandwidth Allocation between On Demand and Broadcast Assume there are n data items, each of size S Each packet is of size R The average time for the sever to service an on-demand request is D=(S+R)/B 0 ; let  =1/D be the service rate Each client generates requests at an average rate of r There are m clients, so cumulative request rate is =m*r For on-demand requests, the average response time per request is T 0 =(1+queue length)*D where “queue length” is given by utilization/(1-utilization) with “utilization’ being defined as  (ref: queueing theory for M/M/1 - take CS 5214 to be offered in Spring 2006)

35. 35 Optimal Bandwidth Allocation between On Demand and Broadcast What are the best frequencies for broadcasting data items? Imielinski and Viswanathan showed that if there are n data items with popularity ratio p 1, p 2, …, p n, they should be broadcast with frequencies f 1, f 2, …, f n, where f i = sqrt(p i )/[sqrt(p 1 )+sqrt(p 2 ) …+sqrt(p n )] in order to minimize the average latency T b for accessing a broadcast data item.

36. 36 Optimal Bandwidth Allocation between On Demand and Broadcast T=T b + T o is the average time to access a data item Imielinski and Viswanathan’s algorithm: Assign D 1, D 2, …, D i to broadcast channel Assign D i+1, D i+2, …, D n to on-demand channel Determine optimal B b, B o to minimize T=T b + T o : Compute T o by modeling on-demand channel as M/M/1 (or M/D/1) Compute T b by using the optimal frequencies f 1, f 2, …, f n Compute optimal B b which minimizes T to within an acceptable threshold L

37. 37 Mobile Caching: General Issues Mobile user/application issues: –Data access pattern (reads vs. 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

38. 38 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? Pertaining To Mobile Computing

39. 39 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)?

40. 40 Weak vs. Strong Consistency Strong consistency –Value read is most current value in system –Invalidation on each write –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., Polling to update TTL or retrieval of new copy of data item if out of date

41. 41 Invalidation Report for Strong Cache Consistency Stateless: Server does not maintain information about the cache content of the clients –Synchronous: An invalidation report is broadcast periodically, e.g., Broadcast Timestamp Scheme –Asynchronous: reports are sent on data modification –Property: Client cannot miss an update (say because of sleep or disconnection); otherwise, it will need to discard the entire cache content Stateful: Server keeps track of the cache contents of its clients –Synchronous: none –Asynchronous: A proxy is used for each client to maintain state information for items cached by the client and their last modification times; invalidation messages are sent to the proxy asynchronously. –Clients can miss updates and get sync with the proxy (agent) upon reconnection

42. 42 Asynchronous Stateful (AS) Scheme Whenever the server updates any data item, an invalidation report message is sent to the MH’s HA via the wired line. A home location cache (HLC) is being maintained in the HA to keep track of data having been cached by the MH. The HLC is a list of records (x,T,invalid_flag) for each data item x locally cached at MH where x is the data item ID and T is the timestamp of the last invalidation of x Invalidation reports are transmitted asynchronously and are buffered at the HA until explicit acknowledgment is received from the specific MH. The invalid_flag is set to true for data items for which an invalidation message has been sent to the MH but no acknowledgment is received Before answering queries from application, the MH verifies whether a requested data item is in a consistent state. If it is valid, it will satisfy the query; otherwise, an uplink request to the HA is issued.

43. 43 Asynchronous Stateful (AS) Scheme When MH receives an invalidation message from HA, it discards that data item from the cache Each client maintains a cache timestamp indicating the timestamp of the last message received by the MH from the HA. HA discards any invalidation messages from the HLC with the timestamp less than or equal to the cache timestamp t received from MH and only sends invalidation messages with timestamp greater than t In the sleep mode, the MH is unable to receive any invalidation message When a MH reconnects, it sends a probe message to its HA with its cache timestamp upon receiving a query. In response to this probe message, the HA sends an invalidation report. The AS scheme can handle arbitrary sleep patterns of the MH.

44. 44 Broadcasting Timestamp Scheme (Synchronous Stateless) Asynchronous Stateful Scheme A. Kahol, S. Khurana, S. K. S. Gupta, P. K. Srimani, An Efficient Cache Maintenance Scheme for Mobile Environment

45. 45 Analysis of AS Scheme Goal: –Cache miss probability –Mean query delay Model constraints: A single Mobile Switching Station (MSS) with N mobile hosts

46. 46 Assumptions M data items, each of size b a bits No queuing of queries when MH is disconnected Single wireless channel of bandwidth C All messages are queued and serviced FCFS A query is of size b q bits An invalidations is of size b i bits Processing overhead is ignored

47. 47 MH Queries Queries follow a Poisson distribution with mean rate Queries are uniformly distributed over all items M in the database

48. 48 Data Item Updates Time between two consecutive updates to a data item is exponentially distributed with rate μ

49. 49 MH states Mobile hosts alternate between sleep and awake modes s is the fraction of time in sleep mode; 0 ≤ s ≤ 1 ω is rate at which state changes (sleeping or awake), i.e., the time t between two consecutive wake ups is exponentially distributed with rate ω

50. 50 A. Kahol, S. Khurana, S. K. S. Gupta, P. K. Srimani, An Efficient Cache Maintenance Scheme for Mobile Environment

51. 51 Hit ratio estimation λ e = (1 – s) λ = effective rate of query generation Queries are uniformly distributed over M items in the database Per-data item (say x) query rate: λ x = λ e /M = [(1 – s) λ/M]

52. 52 Hit rate estimation Queries for a specific data item x by a MH would be a miss in the local cache (which would require an uplink request) in either of two conditions: –[Event 1] During time t, item x has been invalidated at least once –[Event 2] Data item x has not been invalidated during time t, but MH has slept at least once during t

53. 53 A. Kahol, S. Khurana, S. K. S. Gupta, P. K. Srimani, An Efficient Cache Maintenance Scheme for Mobile Environment t-t1t

54. 54 Calculating P [Event 1] Probability density function of a query for x at time t Probability of invalidation in time [0,t]

55. 55 PDF of query for x at time t Probability of no invalidation in time [0,t] Probability of no query in time [t-t 1, t] PDF of state change occurs at t1 Probability of at least one sleep occurred in [0, t-t 1 ] Calculating P [Event 2]

56. 56

57. 57 P miss and P hit P miss = P[Event 1] + P[Event 2] P hit = 1 - P miss

58. 58 Mean Query Delay Let T delay be the mean query delay, then T delay = P hit *0 + P miss T q = P miss T q where T q is the uplink query delay Model up-link queries as M/D/1 queue (assuming there is a dedicated up-link channel of bandwidth C) Model invalidations on down-link channel as M/D/1 queue (assuming there is a dedicated down-link channel of bandwidth C)

59. 59 A. Kahol, S. Khurana, S. K. S. Gupta, P. K. Srimani, An Efficient Cache Maintenance Scheme for Mobile Environment N MHs in cell Uplink query generation rate Query service rate

60. 60 A. Kahol, S. Khurana, S. K. S. Gupta, P. K. Srimani, An Efficient Cache Maintenance Scheme for Mobile Environment Mean invalidation message arrival rate Invalidation service rate

61. 61 A. Kahol, S. Khurana, S. K. S. Gupta, P. K. Srimani, An Efficient Cache Maintenance Scheme for Mobile Environment Effective arrival rate of invalidation messages Query service rate

62. 62 Mean Query Delay Estimation Combine M/D/1 queues Resultant mean query delay T delay = P miss T q Average delay by an uplink query

63. 63 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?

64. 64 States of Operation Data Hoarding Disconnected Reintegration

65. 65 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

66. 66 Coda (2) 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

67. 67 To Cache or Not? Compare static allocation “always cache” (SA-always), “never cache” (SA-never), vs. dynamic allocation (DA) Cost model: –Each rm (read at mobile) costs 1 unit if the mobile does not have a copy; otherwise the cost is 0 –Each ws (write at server) costs 1 unit if the mobile has a copy; otherwise the cost is 0 A schedule of (ws, rm, rm, ws) –SA-always: Cost is 1+0+0+1=2 –SA-never: Cost is 0+1+1+0 = 2 –DA which allocates the item to the mobile after the first ws operation and deallocates after second rm operation: Cost is 0 + allocation/deallocation cost = 0 + 1 (for allocation) + 1 (deallocation) = 2 A schedule of m ws operations followed by n rm operations? Cost=m (always) vs. n (never) vs. 1 (DA)

68. 68 To Cache or Not? Sliding Window Dynamic Allocation Algorithm A dynamic sliding-window allocation scheme SW[k] maintains the last k relevant operations and makes the allocation or deallocation decision after each relevant operation Requiring the mobile client to be always connected to maintain the history information Case “Data item is not cached at the mobile node” –If the window has more rm operations than ws operations, then allocate the data item at the mobile node Case “Data item is cached at the mobile node” –If the window has more ws operations than rm operations, then deallocate the data item from the mobile node Competitive w.r.t. the optimal offline algorithm

69. 69 Web Caching: Case Study - 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, 1998. System intercepts web browsing, providing sophisticated caching and bandwidth saving optimizations for web activity in mobile environments Major features: –Low bandwidth in wireless networks  Caching –Based on TTL-based cache consistency –When TTL expires, check if an object has been updated by using the CRC of an object –Verbosity of HTTP protocol  Perform Protocol Reduction –TCP connection setup time  Try to re-use a single TCP connection –Many responses from web servers are very similar to those seen previously  Use differencing rather than returning complete responses, particularly for CGI-based interactions

70. 70 WebExpress (2) Two intercepts (proxies): one on the client side and one on the server side Caching on both client and on wired network + differencing A Single TCP connection Reduce redundant HTTP header info Reinsert removed HTTP header info on server side

71. 71 References 1.I.R. Chen, B. Gu and S.T. Cheng, “On integrated location and service handoff schemes for reducing network cost in personal communication systems,” IEEE Transactions on Mobile Computing, 2005. 2.A. Kahol, S. Khurana, S.K.S. Gupta and P.K. Srimani, “A strategy to manage cache consistency in a disconnected distributed environment,” IEEE Trans. on Parallel and Distributed Systems, Vol. 12. No. 7, July 2001, pp. 686- 700. 3.Chapter 3, F. Adelstein, S.K.S. Gupta, G.G. Richard III and L. Schwiebert, Fundamentals of Mobile and Pervasive Computing, McGraw Hill, 2005, ISBN: 0-07-141237-9.