Fair K-Mutual Exclusion Algorithm for Peer to Peer Systems Vijay Anand, Prateek Mittal and Indranil Gupta Department of Computer Science University of Illinois Urbana Champaign

A K-Mutual Exclusion Algorithm which provides Motivation Central statistics collection server (PlanetLab, Data Centers) [HP OpenView] [CoMon]. Control and Data logs. Limited bandwidth is a bottleneck. Timeliness of data collection is required. Control over bandwidth (by varying k). Services with limited computational resources. Downloading large multimedia file (Gridftp, CoBlitz). A K-Mutual Exclusion Algorithm which provides Fairness is required.

Definition k Mutual Exclusion problem involves a group of processes, each of which intermittently requires access to an identical resource called the critical section (CS). Safety means that at most k processes, 1≤ k ≤ n may be in CS at any given time. Liveness means that every request for critical section access is satisfied in finite time.

Prior Work & Fairness Prior works rarely accounted for Fairness Optimized the mean time to access the critical section [BV95] [SR92] [RA81]. Fairness [LK00] : FIFO ordering with respect to request timestamps. Access Time = Time to get CS – CS request time. spread = width of distribution across clients. Our Fairness Metric: The access time spread for the critical section should be small across requesting clients across multiple requests . Not a binary property (smaller the better). More practical. Generalization of the FIFO ordering.

Our Contributions Proposed a practical fair algorithm for k-mutual exclusion problem. Minimizes the difference between maximum and mean time to access the critical section. Proved that our algorithm satisfies both safety and liveness requirements. Proposed a fault tolerant methodology for our algorithm using Chord peer to peer system. Showed that it is resilient against churn.

System Model Communication channel is reliable and does not duplicate messages. Message delivery to the destination is time bounded. No Joins and failures: We handle failures by relying on chord DHT. Constant critical section (CS) time. Generalizes to varying but known CS times.

First Cut Algorithm 1 2 3 4 Token Based Algorithm (K Tokens). Obtained from a real world scenario : Cinema hall with K ticket counters. Customer has no idea about the length of the queues and picks the queue randomly. 1 2 3 4 This approach gives good average time to get the ticket (token). No load balancing, thus access time spread is very high.

Algorithm(2): Coordinator Coordinator guides customers to the ticket counters in a round robin manner. Presence of coordinator leads to centralized solution (single point of failure). 1 2 3 4 2 3

Algorithm(3): Distributed Approach Every customer entering the hall acts as a coordinator and guides the next customer to the round robin ticket counter. It provides load balancing of requests for tickets among the counters. 1 2 3 4 2 This scenario exactly maps to our k-mutual exclusion Algorithm. 3 4

Algorithm(3): Distributed Approach Every customer entering the hall acts as a coordinator and guides the next customer to the round robin ticket counter. It provides load balancing of requests for tickets among the counters. 1 2 3 4 3 4 1 This scenario exactly maps to our k-mutual exclusion Algorithm.

Distributed Data Structures in Algorithm Entry in to the cinema hall – Single mutual exclusion. Dynamic tree is used to represent the queue (O (log N)) Tree is based on the path reversal technique by [NTA96]. K- Counter queues – K distributed token queues Coordinator Node Has addresses of the tails of the k token queues, and Counter variable – Incremented in round robin way. Passes both to the next element in the queue (DY Tree).

Initial Configuration: Node 3 is the coordinator Example N = 8, K =3 Node With Token 1 2 3 1 Coordinator Node 1 2 3 Father Pointer 8 Child Pointer 7 4 6 5 Initial Configuration: Node 3 is the coordinator

Coordinator/root Node Example Node With Token 1 2 3 1 Coordinator/root Node 1 2 3 Father Pointer 8 Child Pointer Message_Child 7 Message_Request 4 6 5 Message_Token_ Locations 4 2 3 2 Node 4 Requests CS

Example 4 2 3 2 4 5 3 3 Node With Token Coordinator Node 1 2 3 Father Pointer 8 Child Pointer Message_Child 7 4 Message_Request 6 5 Message_Token_ Locations 4 2 3 2 4 5 3 3 Node 5 Requests CS

Node 5 has been appended to the Child queue Example Node With Token Coordinator Node 1 2 3 Father Pointer 8 Child Pointer 4 5 7 6 4 5 3 3 Node 5 has been appended to the Child queue

Example 7 5 6 2 Node With Token Coordinator Node 1 2 3 Father Pointer 8 Child Pointer 6 4 5 7 7 5 6 2 Node 6 and 7 Request CS (Not showing the formation of privileged queue)

Example 7 5 6 2 Node With Token Coordinator Node 1 2 3 Father Pointer 8 Child Pointer 6 4 5 7 7 5 6 2 Node 1 Exits CS

Experiment Methodology Critical Section duration = 10s Number of nodes = 100 Number of tokens = 3 Latencies LAN Setting : Normalized 1 sec between every pair of nodes WAN Setting : King Data Set (Highly Heterogeneous) (average RTT = 182ms , Maximum RTT = 800 ms) Compared with BV95[Best known algorithm] Remaining algorithms have worse mean access times.

MTTT: Mean Time to get the Token Our Algorithm and BV95 in LAN Setting Our Algorithm and BV95 in WAN Setting Our algorithm is comparable to BV95 (similar MTTT values under both settings)

Results: Fairness Globally Maximum Time to get the token Vs Request rate More than1600s BV95 in LAN Setting Our Algorithm in LAN Setting 370s Access time spread (Maximum - Mean) for our algorithm is less than15s, whereas for BV95 it is more than1250s.

Trade off Average Messages Vs Request Rate Message Complexity Our Algorithm in LAN Setting Message Complexity is same in both the algorithms (O (log N)) BV95 in LAN Setting This Increase in Average message is due to 1) Additional constant number of messages (message_child etc). 2) Unlike BV95 our algorithm does not cache requests for CS to preserve fairness.

Conclusion A Practical Fairness Metric: Access Time Spread. A New Distributed Fair Mutual Exclusion Algorithm Similar performance for MTTT values compared to BV95. An order of magnitude performance Improvement in fairness metric (15s Vs 1250s). Trade off: Additional constant number of messages.