[eternalban]

Not surprised or disappointed, really. My take on RAFT is that it's basically Paxos for elections and a more relaxed regime in between.

But Brooker's post (in my OP) actually addresses VR vs Paxos distiction:

It's easy to believe that these two protocols are, in fact, the same. That doesn't appear to be the case. A new paper by van Renesse et. al., titled Vive La Difference: Paxos vs. Viewstamped Replication vs. Zab, looks at Paxos and VR through the lenses of refinement and abstraction, and finds they are not exactly equivalent due to design decisions in the way they refine a model the paper calls Multi-Consensus. One of the key differences is active (Paxos) vs. passive (VR) replication: "Passive vs. Active Replication: In active replication, at least f + 1 replicas each must execute operations. In passive replication, only the sequencer executes operations, but it has to propagate state updates to the backups."

Which reminds of ZAB (of Zookeepr fame), another protocol languishing in relative obscurity.

Anyway, thanks for your input. I have this thing for underdogs and this VR vs Paxos thing is a very minor cause, and I guess you triggered me there. /g

[_vvhw]

"My take on RAFT is that it's basically Paxos"

You're right that Raft is Paxos for the leader election phase, in the same way that VR is Paxos for the view change phase, or that Paxos is basically VR's view change but for deciding a value.

But a better way of saying this would be that Raft is Multi-Paxos (https://news.ycombinator.com/item?id=23123701), because Raft is much more than Paxos (in the same way that VR is more than Paxos because it not only decides on a value/leader but is also a protocol for replication). I think this is where our misunderstanding came in.

Yes, I've read the linked "Vive La Difference" paper. As the excerpt makes clear, one of the key differences is active replication (Paxos: with multiple concurrent processes that want to decide on a value) vs passive replication (Multi-Paxos variants: VR and Raft and ZAB all protocols with a single leader elected for a given term/view during which multiple rounds of replication take place).

The name Multi-Paxos just means that the first round of Paxos for leader election is reused for multiple rounds of replication, driven by a single leader instead of competing processes always using the minimum two-phase Paxos.

"I have this thing for underdogs"

Yes, me too, and that's why I tried to show that VR is no less than Multi-Paxos in my original comment, and that Raft is not newer than Multi-Paxos in my follow-up. It would be great for VR to receive the recognition it deserves.

[eternalban]

Well, in that case we mildly disagree. My take is this:

That functionally M-Paxos and Raft are equivalent does not make them the equivalent. RAFT uses a protocol that looks awfully like Paxos for election of a single leader - so it has nothing to do with multi-Paxos (as I understand it). But that L.E. phase + the interim regime gives you functional equivalence to Multi-Paxos.

[_vvhw]

Happy to mildly disagree!

"RAFT uses a protocol that looks awfully like Paxos for election of a single leader"

Agreed.

"so it has nothing to do with multi-Paxos (as I understand it)"

Except that Raft is not only a protocol for single leader election, it's also a replication protocol (see the "AppendEntries" message), and that's why it is Multi-Paxos. Multi-Paxos is just the category or classification for a family of consensus protocols that use the strategy of single leader election and replication with terms/views/epochs (the "interim regime" you refer to) for strict serializability. This is the passive replication leader/follower primary/backup strategy.

Outside of Multi-Paxos, there are also consensus protocols that achieve strict serializability with Paxos but without electing a single stable leader, e.g. FastPaxos. These exploit low latency between the client and all replicas, but this is not always available, or may suffer from tail latency issues, hence implementations such as Raft use the MultiPaxos strategy of a stable leader, which may be better connected to the rest of the cluster than the client.

As an implementation, depending on how you zoom, Raft is very different to VR and ZAB, but it's still in the same Multi-Paxos class since it reuses a single stable leader derived from one instance of Paxos for "multiple" rounds or instances of replication, hence "Multi-" "Paxos".

At least this is how I understand it from Heidi Howard and others who seem to share this "view".

[eternalban]

I guess my issue here is calling all these "paxos" when 2 (VR and VS) predate Paxos.

Anyway, did you check out Egalitarian Paxos? I think this protocol deserves more love, specially in WAN contexts (there is a ref. impl. on github):

https://www.usenix.org/system/files/nsdip13-paper14.pdf

[_vvhw]

> I guess my issue here is calling all these "paxos" when 2 (VR and VS) predate Paxos.

Definitely. All VR needs now is a paper called "VR Made Famous" because it's already been made simple, easy, fast and understandable! And, after all, it was first.

Thanks for the reference to Egalitarian Paxos, that's a great example of active replication in the Paxos (and not Multi-Paxos) sense.