Saltar a contenido

Swim Paper Vs Camunda Defaults

Comparación directa entre los parámetros y mecanismos del paper original SWIM (Das/Gupta/Motivala 2002) y los defaults de Camunda en SwimMembershipProtocolConfig. Resultado: Camunda valida la mayoría de los hyperparameters del paper escalando agresivamente la latencia (T'=1s vs paper 2s) y duplicando el indirect probing (k=2 vs paper k=1). Brechas: round-robin probe target selection no está expuesto en config — riesgo teórico de detection time unbounded en clusters muy grandes.

Tabla comparativa de parámetros

Parámetro Paper (DSN'02) Camunda default Delta Razón probable
Protocol period (T' / probeInterval) 2 sec 1 sec -50% Camunda prioriza speed of detection — workloads cluster Zeebe son sensibles a latency de leader re-election
Indirect probe count (k / gossipFanout) 1 2 +100% Camunda más conservador con false positives — GC pauses en JVM son comunes y costosas
Round-trip timeout "smaller than protocol period" (~T'/3) 2 sec (probeTimeout) 2× T' VIOLACIÓN aparente del constraint. Ver "Brecha 1" abajo
Suspect probes No explícito (1 implícito) 3 (suspectProbes) +200% Suspicion mechanism del paper requiere 1 timeout; Camunda lo extiende con 3 reintentos antes de Suspect
Suspicion timeout λ · log(N) × T' (varía con N) 10 sec (failureTimeout) Constante Trade-off: simplicidad operacional vs adaptive sizing
Gossip interval Per-period (no separado) 250 ms (gossipInterval) Más frecuente Camunda separa gossip de probe — mayor freshness para listeners (ej: Raft leadership)
Sync interval No mencionado 10 sec (syncInterval) N/A Mecanismo no del paper — viene de extensiones Atomix/Scalecube
Piggyback count (λ · log(N)) λ = 3 (experimentos) No expuesto en config N/A Ver "Brecha 2"

Validaciones

✓ Camunda mantiene Strong Completeness

Tanto el paper como Camunda implementan la garantía formal: toda muerte se detecta eventualmente por todos los miembros sanos. Los suspectProbes = 3 extras solo retrasan, no eliminan, la detección.

✓ Camunda implementa Suspicion mechanism con incarnation numbers

Visible en: - broadcastDisputes = true (default) — disputes propagan vía broadcast (no solo gossip), señal de que hay un mecanismo de version comparison. - notifySuspect = false (default) — los nodos suspected NO son notificados directamente. En su lugar, ven la suspicion vía gossip y entonces incrementan su incarnation (alineado con el paper, donde solo el propio miembro incrementa).

Ver ../concepts/incarnation-numbers para el mecanismo completo.

✓ Camunda implementa infection-style dissemination

broadcastUpdates = false (default) — updates van por gossip, no broadcast. Coincide con la decisión del paper de eliminar multicast.

✓ Threading single-threaded

swimScheduler = Executors.newSingleThreadScheduledExecutor(...);

El paper no especifica threading model, pero single-threaded es coherente con la asunción de que la lista de membership es manipulada secuencialmente. Bonus: alinea con la filosofía global de Zeebe (../concepts/stream-processing).

Brechas / observaciones críticas

Brecha 1: probeTimeout = 2s viola el constraint del paper

Paper (literal):

"Note that the protocol period T' has to be at least three times the round-trip estimate."

Camunda config: - probeInterval = 1 sec (= T') - probeTimeout = 2 sec (= 2 × T')

El timeout es mayor que el período. Esto significa que cuando llega el timeout, el siguiente protocol period ya está en curso — el detector está "atrasado" estructuralmente.

Hipótesis: en la implementación de Atomix, los probes son asíncronos (se solapan), no estrictamente secuenciales por período. Esto preserva la garantía pero rompe el modelo simple del paper. Verificar en source de scalecube-cluster si el probe loop es batch-per-period o continuous.

Brecha 2: Round-robin probe target selection no expuesto

El paper introduce explícitamente la modificación 4.3 para garantizar Time Bounded Completeness:

"Selecting ping targets not randomly from this list, but in a round-robin fashion. ... This bounds the worst case detection time of a process failure of any member by 2N · T'."

Sin round-robin, el paper warns:

"A pathological selection of ping targets across the group might lead to a large delay in the first detection of the process failure anywhere in the group. In the extreme case, this delay could be unbounded as the failed process might never be chosen as a ping target by any other non-faulty process."

Camunda: la config SwimMembershipProtocolConfig NO tiene un flag useRoundRobinProbes. La implementación de scalecube-cluster (que Atomix integra) usa random probe selection según la documentación pública.

Impacto práctico para Camunda: - Para clusters de 3-15 nodos (típico Zeebe): worst case detection es probabilísticamente O(N) periods con muy alta probabilidad — no es unbounded en la práctica. - Para clusters > 50 nodos: el riesgo crece. Pero Camunda raramente opera a esa escala. - Recomendación de discovery: confirmar en source si Camunda parchea scalecube con round-robin o asume el riesgo.

Brecha 3: Buffer piggyback count no parametrizado

Paper:

"Each element is piggybacked at most λ · log(N) times."

Con λ = 3 (experimental) y N = 15 (cluster Intuit típico): 3 × log2(15) ≈ 12 piggybacks por update.

Camunda no expone este parámetro. La implementación interna decide; sin saber el valor, no podemos validar la coverage promise (N - N^(-(2λ-2))).

Impacto: un valor demasiado bajo (λ = 1) deja updates sin propagar a una fracción del cluster — silent loss. Un valor demasiado alto satura los pings con history vieja.

Brecha 4: Suspicion timeout fijo, no escalado con N

Paper:

"Suspicion timeout = λ · log(N) × T' ... in our experiments, we use the average measured round-trip time to set a protocol period with probability of false positive (1 - qS · qF)^k · (1 - qF) · ..."

Para λ = 3, T' = 2s, N = 50: timeout = 3 × log2(50) × 2 ≈ 34 segundos.

Camunda usa constante 10 sec independiente de N. Implicación: - Para N pequeño (<10): demasiado conservador, retrasa rebalance innecesariamente. - Para N grande (>50): demasiado agresivo, false positives bajo carga.

Trade-off de Camunda: simplicidad operacional > adaptive sizing. Razonable dado que Zeebe rara vez opera con N > 30 brokers.

Lecciones aplicables al MVP

1. Si implementas SWIM custom, copia los parámetros del paper

No improvises. Los defaults T'=2s, k=2, λ=3 están validados experimentalmente. Camunda derivó los suyos pero a costo de divergencias del paper que pueden morder en edge cases.

2. Implementa round-robin probe target selection

Es trivial vs random (1 línea de código extra) y elimina el riesgo de detection time unbounded. No hay razón para no hacerlo.

3. Persiste incarnation locally

Si tu nodo reinicia y vuelve con incarnation = 0, mensajes Suspect viejos pueden override tu Alive. Persiste en disk con cada increment.

4. Para MVP single-region < 10 nodos: usa Postgres en vez de SWIM

Las brechas y trade-offs del paper se vuelven irrelevantes a esa escala. Una tabla cluster_members con last_seen y un cron de cleanup es suficiente.

Métrica SWIM (con Camunda defaults) Postgres-based heartbeat
LOC implementación ~5000 ~200
Detection time 5-10 sec 30 sec (típico)
Network load O(1) per node O(N) per primary
Operational complexity Alta (debug gossip flows) Baja (SQL queries)
Adecuado hasta ~100 nodes ~10 nodes

Gaps abiertos

  • Verificar implementación de probe loop en scalecube-cluster: ¿secuencial-per-period o async overlapping? Resuelve Brecha 1.
  • Verificar si scalecube parchea round-robin probe selection: si no, confirma Brecha 2 como riesgo real.
  • Encontrar el piggyback count interno: revisar SwimMembershipProtocolConfig extendido o source de scalecube.
  • Medir false positive rate en Camunda bajo packet loss controlado: replicar experimento del paper (10% loss, 17 nodes joining sequentially).

Cross-refs