hrefna, 30 days ago

@julian But that could be specified at the protocol level. It isn't, but it is kind of weird

There are entire sections on it for Dynamo (first image), Tiara discusses it extensively in the posted snippet (second image) and in multiple other sections, and it is covered as something to address in Requirements for Signaling Protocols (RFC 3726).

These all have multiple sections addressing different parts of this problem and solve it with different levels of flexibility, but they all address it.

Crash resistance. Observe that Tiara can be separated into disconnected components by the crash of even a single process. Tiara can be fortified against separation due to crashes in the following manner. At the bottom, each process maintains a crash-redundancy link to its right neighbor’s neighbor. That is, the bottom level list becomes doubly connected. Thus, it can tolerate a single crash. The crash tolerance can be further improved by adding similar links to more distant processes. Since these links only span a fixed number of processes, their construction does not affect the asymptotic complexity of stabilization of Tiara. Note that in an asynchronous model there is no reliable way to distinguish a crashed process from a slow one [15]. Thus, to accomplish this, the processes need to be equipped with failure detectors [9, 10]. A failure detector alerts the process if its neighbor crashes. Then, Tiara stabilizes to a legitimate state corresponding to the system without the crashed process
5.10.3. Graceful Handling of NSIS Entity Problems NSIS entities SHOULD be able to detect a malfunctioning peer. It may notify the NSIS Initiator or another NSIS entity involved in the signaling process. The NSIS peer may handle the problem itself e.g., switching to a backup NSIS entity. In the latter case note that synchronization of state between the primary and the backup entity is needed.