FASE 4 Evaluación del impacto de la estrategia

The schema used to define round numbers presented in the previous section, that is, as a vector of the form〈MCount:mCount, Id, RType, S 〉, should fit most of applica- tion scenarios. However, there are some specific cases in which this schema should be adapted for better performance. There are two main points on doing these adap- tations: the likeliness of collisions and how they are recovered, and what type of round follows each other.

For example, if collisions are frequent in the system, then fast rounds should not be used because the recovery cost could outweigh the economy provided by fast rounds. If fast rounds are used in conjunction with coordinated recovery, then they should be followed by single-coordinated rounds. In the case of uncoordinated recovery, fast rounds should be followed by multicoordinated fast rounds. (See Section3.4.4.)

In the case of the example, where some fast rounds should be followed by other fast rounds, using the record described above would force the use of rounds with different Id or Count field. Because recovery relies on a process knowing exactly what is the next round number, this schema would not work. A possible solution is to change how the field RType is interpreted. For example, letting all RType in the range 0 to 5 be interpreted as fast, instead of simply 0, and allowing a round number to be incremented without changing any but the RType field.

The set of coord-quorums can be defined at run-time, considering the status of the system when a new round is created. To ensure liveness, multicoordinated

rounds should be followed by single-coordinated rounds (See Section3.4.7). How- ever, this transition does not have to be abrupt and could be done through a series of multicoordinated rounds with smaller quorums, minimizing the risk of collisions while still allowing the benefits of multicoordination.

Below we present a few general scenarios and discuss how round numbers and quorums could be defined for them. These scenarios are not necessarily disjoint, and real world systems would probably share the characteristics of both of them, as well as other relevant ones. Hence, a per-case analysis is needed to find the best solution. Notice that none of the Paxos algorithms requires the ordered use of bal- lot numbers and that coordinators are allowed to skip rounds—possibly based on the the dynamics of the environment it is in. However, because collision recovery explores the sequential execution of rounds, skipping rounds could prevent efficient recovery and therefore the rounds’ configuration should be defined a priori as pre- cisely as possible.

Highly reliable clustered systems

Clustered systems connected through high-speed networks have a large probability of spontaneously ordering the messages sent to the same destinations. In such sys- tems, acceptors executing a fast round are likely to accept the values in the same order. Therefore, values can be learned in two communication steps, even when conflicting proposals are made.

In such a scenario, a large sequence of fast rounds followed by single-coordinated rounds seem the best configuration: most of the time values are fast learned and, in the rare case of conflicts, they are solved by the variant of uncoordinated recov- ery presented in Section 3.4.4. Coordinators can always resort to the next single- coordinated round to ensure liveness if uncoordinated recovery does not succeed.

For this scenario, the values of the RType field in the basic approach can be mapped to a range of many fast rounds followed by classic rounds, as we mentioned before. By dividing RType in a major and minor component, as we did with Count , the number of successive fast rounds is bounded only by the memory size.

If conflicts are rare but tend to be persistent and require coordinated recovery, then a solution is to map RType’s even values to fast rounds and odd values to single-coordinated classic rounds.

Crash prone clustered systems

Remember that for a fast round to progress, more than two thirds of all acceptors must be functional and reachable. Not even resorting to classic rounds would allow the protocol to progress if this condition is not met. As we explained in Section2.3.2, to progress with fewer acceptors in classic rounds, the number of acceptors needed

for fast rounds to terminate may increase to up to three quarters of their total num- ber. In a scenario where more than one third of acceptors can crash, fast rounds should not be used.

In such a scenario, even though spontaneous ordering cannot be used to achieve fast termination, it can be used to improve availability; with multicoordinated rounds, progress can be achieved in the absence of any minority of coordinators for a given round. If acceptors and coordinators are collocated, for example, then the round can tolerate any minority of acceptor-coordinator crashes.

Using the same round number definition as in the previous sections, RType is permanently set to classic round. The leader starts new rounds whenever the num- ber of functional and reachable coordinators falls below a certain threshold. The extra availability given by multicoordinated rounds can be used to relax failure de- tection requirements.

Highly loaded and time constrained systems

If most proposed commands commute, either multicoordinated or fast rounds can be used, with the second option having the advantage of smaller latency. However, even though commands do not semantically conflict, they do contend for stable storage when accepted at the acceptors. To mitigate the performance loss due to I/O, the load of accepting values can be distributed over the acceptors by randomly selecting a quorum to whom send proposals. Since fast rounds require quorums of more than two thirds of the acceptors, each acceptor must bare the load of at least two thirds of the proposals. Using classic rounds, the load over each acceptor may be lowered to roughly half of the acceptances. Since coordinators do not need to access stable storage, the fewer stable storage accesses at the acceptors fairly makes up for the extra communication delay with state-of-the-art networks.

Under particularly high load or if other tasks must be performed for each pro- posal, just forwarding proposals may become a too demanding task for a single coordinator. For example, if coordinators deal with proposers in an open network and must authenticate or decode their proposals before forwarding them to accep- tors. In such a scenario, multicoordination can be used to alleviate the load on each coordinator to roughly half. Round numbers can be specified as in the previous scenario.

Conflict prone

In widely distributed systems or under high load, spontaneous ordering cannot be expected and non-commutable proposals often result in conflicts. In such environ- ments, if non-commutable commands prevail, then the algorithms will always end up resorting to single-coordinated classic rounds to finish.

In such an environment, it does not make sense to have fast nor multicoordi- nated rounds, and round numbers can be defined as the set of integer and parti- tioned among a finite set of coordinators by some module function. For an infinite set of coordinators or for having each coordinator as the leader of infinitely many consecutive rounds, a simplified round number of the form〈MCount:mCount, Id〉 could be used.