Service Management in PCN Systems

Transcription

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 1 Service Management in PCN Systems Managing services in mobile environments Server VLR VLR How does the server find new VLR? Too much overhead in contacting HLR 2 1

2 PCN Systems: Proxy-Based Solution Per-User Service Proxy Server Proxy Client 3 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 4 2

3 Static Service Proxy Proxy is located at a fixed location Inefficient data route delivery Server Client Proxy 5 Mobile Service Proxy Proxy could move with the client if necessary Proxy informs servers of location changes Server Proxy/ Client Proxy/ Client Proxy/ Client 6 3

4 Location/Service Management Decoupled Model Traditionally, service and location management are decoupled HLR / VLR Proxy Client 7 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 8 4

5 Integrated: Centralized Scheme The proxy is centralized and colocated 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 9 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 10 5

6 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 11 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 12 6

7 λ σ γ CMR SMR T τ 1 τ 2 τ 3 M cs N s P InA P OutA call to mobility ratio, e.g., λ / σ. 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. service request to mobility ratio, e.g., γ / σ. the average round trip communication cost between a VLR and the HLR (or between a VLR and the server) per message. the average round trip communication cost between the anchor and a VLR in an anchor area per message. the average round trip communication cost between two neighboring VLRs in an anchor areas per message. the average round trip communication cost between two neighboring VLRs per message. the number of packets required to transfer the service context. the number of server applications concurrently engaged by the MU. the probability that a MU moves within the same anchor area when a VLR boundary crossing movement occurs. the probability that a MU moves out of the current anchor area when a VLR 13 Cost Model Performance metric total communication cost per time unit: C total = Cupdate * σ + Csearch * λ + Cservice * γ 3 basic operations Location update ( C update ) cost for updating the location of MU and service proxy (sometimes, service context transfer) Call delivery ( C search ) cost for locating a MU to deliver a call Data service requests ( C service ) cost for MU to communicate with server through proxy 14 7

8 Costs for Centralized and Fully Distributed Schemes Scheme/Cost Location update Call delivery Service request Centralized Distributed C update = T Cost to inform the location database at the HLR of the new VLR Cupdate = T + M cs *τ 3 + N st T :cost to inform the HLR of the new VLR M cs *τ 3 :cost to transfer service context between two neighboring VLRs for the proxy move N s T :cost to update Ns application servers with new location of MU C search = T Cost to locate the MU and deliver the call from the HLR to VLR C search = T Cost to locate the MU and deliver the call C service = T + T Round trip cost from MU to proxy and from proxy to server C service = T Cost from the service proxy colocated at the current VLR to the server 15 Performance Evaluation-Results Cost rate under different CMR and SMR values 16 8

9 Cost Rate Performance Evaluation-Results Centralized Fully distributed Dynamic anchor Static anchor CMR Cost rate under different CMR values 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 17 update costs Cost Rate Performance Evaluation-Results Centralized Fully distributed Dynamic anchor Static anchor SMR Cost rate under different SMR values 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 18 9

10 Cost Rate Performance Evaluation Results Decoupled Schemes Integrated Schemes IS SMR 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 19 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 20 10

11 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 21 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 22 11

12 Dissemination: Pull Pull-oriented dissemination can run into trouble when demand is extremely high Web servers crash Bandwidth is exhausted client client client client server client client help client 23 Dissemination: Push Server pushes data to clients No need to ask for data Ideal for broadcast-based media (wireless) client client client client server client client Whew! client 24 12

13 Broadcast Disks server 5 6 Schedule of data blocks to be transmitted 25 Broadcast Disks: Scheduling Round Robin Schedule Priority Schedule

14 Priority Scheduling (2) Random Randomize broadcast schedule Broadcast "hotter" items more frequently Periodic Allows mobile hosts to sleep 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 27 "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) ) 28 14

15 Sample Schedule, From Paper Relative frequencies 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! 30 15

16 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 31 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 32 16

17 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 33 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) 34 17

18 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. 35 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 36 18

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

20 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)? 39 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 40 20

21 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 41 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 42 uplink request to the HA is issued. 21

22 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 43 the MH. Asynchronous Stateful Scheme Broadcasting Timestamp Scheme (Synchronous Stateless) 44 A. Kahol, S. Khurana, S. K. S. Gupta, P. K. Srimani, An Efficient Cache Maintenance Scheme for Mobile Environment 22

23 Analysis of AS Scheme Goal: Cache miss probability Mean query delay Model constraints: A single Mobile Switching Station (MSS) with N mobile hosts 45 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 46 23

24 MH Queries Queries follow a Poisson distribution with mean rate λ Queries are uniformly distributed over all items M in the database P( N( t) = n) = n ( λt) λt n! e 47 Data Item Updates Time between two consecutive updates to a data item is exponentially distributed with rate µ 48 24

25 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 ω 49 A. Kahol, S. Khurana, S. K. S. Gupta, P. K. Srimani, An Efficient Cache Maintenance Scheme for Mobile Environment 50 25

26 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] 51 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 52 26

27 t-t1 t A. Kahol, S. Khurana, S. K. S. Gupta, P. K. Srimani, An Efficient Cache Maintenance Scheme for Mobile Environment 53 P[Event 1] = Calculating P [Event 1] t λ xt ( λxe ) µ e µ x µ Mµ dx dt = = λx + µ (1 s λ + Mµ 0 0 ) Probability density function of a query for x at time t Probability of invalidation in time [0,t] 54 27

28 PDF of state change occurs at t1 Calculating P [Event 2] P[Event 2] = t λxt µ t λxt1 ωt1 ω ( t t1 ) ( λ e e ) e ωe ( 1 e ) x 0 0 dt dt 1 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] Probability of at least one sleep occurred in [0, t-t 1 ] 55 P[Event 2] = t λxt µ t λxt1 ωt1 ω ( t t1 ) ( λ e e ) e ωe ( 1 e ) x 0 0 dt dt 1 = ωλx λ e λ e ω + λ ( ω + λ ) µ + λ µ + λ + ω µ + λ + ω e x x 2 x e + ω 56 28

29 P miss and P hit P miss = P[Event 1] + P[Event 2] P hit = 1 - P miss 57 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) 58 29

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

31 Effective arrival rate of invalidation messages Query service rate A. Kahol, S. Khurana, S. K. S. Gupta, P. K. Srimani, An Efficient Cache Maintenance Scheme for Mobile Environment 61 Mean Query Delay Estimation Combine M/D/1 queues Average delay by an uplink query Resultant mean query delay T delay = P miss T q T q ~ 2µ q λq + λi = ~ 2µ q µ q λq + λi 62 31

32 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? 63 States of Operation Data Hoarding Reintegration Disconnected 64 32

33 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 65 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 66 33

34 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 =2 SA-never: Cost is = 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 = (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) 67 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 68 34

35 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: , 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 69 WebExpress (2) A Single TCP connection Reduce redundant HTTP header info Reinsert removed HTTP header info on server side Caching on both client and on wired network + differencing Two intercepts (proxies): one on the client side and one on the server side 70 35

36 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, 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 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: