[ClusterLabs] RRP is broken ... in what ways? (Was: corosync caused network breakdown)

[Jan Pokorný]

On 08/04/19 19:08 +0200, Jan Friesse wrote:
> Anyway. RRP is broken,

Since this is repeatedly rehashed on this list without summarizing
*what* is that much broken[1] while serving (rather well, I think)
last 8+ years, perhaps it would deserve some wider dissemination
incl. *why* is that.

Closest thing to come to mind is this, though I don't think
it's a well known reference:
https://corosync.github.io/corosync/doc/presentations/2017-Kronosnet-The-new-face-of-corosync-communications.pdf#page=3

In addition, there are minor notes here and there to be found, e.g.,
on the topic of the networks being presumably of comparable
characteristics with RRP [2,3]:

> It should probably be documented somewhere but may not be, with
> redundant ring, both rings must be of approximately the same
> performance.

> The protocol is designed to limit to the speed of the slowest ring
> - perhaps this is not working as intended.

[1] https://lists.clusterlabs.org/pipermail/users/2019-March/025491.html
[2] https://discuss.corosync.narkive.com/jUynoGxv/totem-implementation-is-unreliable-ring-faulty-and-retransmit-list#post2
[3] https://lists.clusterlabs.org/pipermail/pacemaker/2011-August/058536.html

Can you perhaps give a definite answer here to arising "what" and "why",
also perhaps to provide a credible incentive to upgrade out of something
just sketchily referred to as "broken", please?

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20190410/baa21743/attachment.sig>