Independent Submission                                  Douglas Dohmeyer
Internet-Draft                                    Independent Researcher
Intended status: Informational                           2 December 2025
Expires: 5 June 2026

ChainSync: A Synchronization Protocol for Strict Sequential Execution in
                      Linear Distributed Pipelines
                      draft-dohmeyer-chainsync-00

Abstract

   ChainSync is a lightweight application-layer protocol that runs over
   reliable TCP connections to synchronize a fixed linear chain of
   distributed processes (labeled A, B, C, ..., N) such that they
   execute their local tasks in strict sequential order (A -> B -> C ->
   ... -> N) *and only after every process in the chain has confirmed it
   is ready*.

   The protocol uses three distinct phases:

   1.  Forward "readiness" wave (SYNC -> READY propagation from head to
       tail)

   2.  Backward "start" wave with deferred execution and watching (START
       propagation from tail to head)

   3.  Forward "completion" wave that triggers execution in the required
       order and provides clean backward-propagating exit

   The design guarantees strict ordering even when nodes become ready at
   very different times and requires only point-to-point TCP connections
   along the chain -- no central coordinator is needed.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Douglas Dohmeyer           Expires 5 June 2026                  [Page 1]
Internet-Draft                  ChainSync                  December 2025

   This Internet-Draft will expire on 5 June 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Topology and Configuration  . . . . . . . . . . . . . . .   3
     1.3.  States  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.4.  Message Types . . . . . . . . . . . . . . . . . . . . . .   4
     1.5.  Protocol Operation  . . . . . . . . . . . . . . . . . . .   4
       1.5.1.  Phase 1 -- Readiness Collection (Forward Wave)  . . .   4
       1.5.2.  Phase 2 -- Start Trigger Propagation (Backward
               Wave) . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.5.3.  Phase 3 -- Ordered Execution and Completion (Forward
               Wave) . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.6.  Waiting in WATCH State  . . . . . . . . . . . . . . . . .   5
     1.7.  Example Message Flow (A-B-C-D)  . . . . . . . . . . . . .   5
   2.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   4.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Many distributed workflows (pipeline parallelism in machine-learning
   training, staged data processing, multi-organization business
   processes, ordered multi-phase computation, etc.) require that tasks
   execute in a fixed order across different machines, yet must not
   begin until every participant is ready.

   Standard barriers do not enforce execution order.  Token-passing or
   leader-based schemes introduce complexity and single points of
   failure.

Douglas Dohmeyer           Expires 5 June 2026                  [Page 2]
Internet-Draft                  ChainSync                  December 2025

   ChainSync solves this with a simple, fully decentralized three-wave
   algorithm on a line topology that guarantees:

   *  No process starts until the entire chain is ready.

   *  Execution order is strictly A -> B -> ... -> N.

   *  Clean backward-propagating exit after N finishes.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.2.  Topology and Configuration

   The processes form a static logical chain:

   (Head) A <-> B <-> C <-> ... <-> N (Tail)

   Each process knows:

   *  IP address and port of its predecessor (Head has none)

   *  IP address and port of its successor (Tail has none)

   *  Whether it is head, tail, or intermediate (inferable from
      presence/absence of predecessor/successor)

   Each adjacent pair maintains a single persistent bidirectional TCP
   connection.

1.3.  States

           +==========+=======================================+
           | State    | Meaning                               |
           +==========+=======================================+
           | SYNC     | Initial state; waiting for READY from |
           |          | predecessor (Head starts here but     |
           |          | moves to READY when locally ready)    |
           +----------+---------------------------------------+
           | READY    | Chain segment to the left is ready;   |
           |          | has sent READY to successor           |
           +----------+---------------------------------------+
           | WATCH    | Has propagated START leftward;        |

Douglas Dohmeyer           Expires 5 June 2026                  [Page 3]
Internet-Draft                  ChainSync                  December 2025

           |          | waiting for COMPLETE from predecessor |
           +----------+---------------------------------------+
           | START    | Currently executing its local task    |
           +----------+---------------------------------------+
           | COMPLETE | Local task finished; has sent         |
           |          | COMPLETE to both directions as        |
           |          | required                              |
           +----------+---------------------------------------+

                                 Table 1

1.4.  Message Types

   Messages are simple ASCII text lines terminated by LF.  Recommended
   format:

   <COMMAND>[:<ROUND-ID>]\n

   Defined commands:

   *  READY[:<ROUND-ID>]

   *  START[:<ROUND-ID>]

   *  COMPLETE[:<ROUND-ID>]

   <ROUND-ID> is optional but RECOMMENDED (e.g., UUID) to support
   multiple concurrent rounds on the same connection.  Implementations
   running only one round at a time MAY omit it.

1.5.  Protocol Operation

1.5.1.  Phase 1 -- Readiness Collection (Forward Wave)

   *  Head (A), when locally ready, moves SYNC -> READY and sends READY
      to successor.

   *  Every other node starts in SYNC.  When it receives READY from
      predecessor *and* becomes locally ready, it moves SYNC -> READY
      and sends READY to successor.

   *  When tail (N) enters READY, Phase 2 begins automatically.

1.5.2.  Phase 2 -- Start Trigger Propagation (Backward Wave)

   *  Tail, upon entering READY, sends START to predecessor and moves to
      WATCH.

Douglas Dohmeyer           Expires 5 June 2026                  [Page 4]
Internet-Draft                  ChainSync                  December 2025

   *  Intermediate node, upon receiving START from successor:

      1.  Sends START to its predecessor (if any)

      2.  Moves to WATCH and waits for COMPLETE from predecessor

   *  Head, upon receiving START, has no predecessor and therefore moves
      directly to START and begins execution.

   This phase completes in O(n) messages and guarantees every node knows
   the entire chain is ready before any node starts.

1.5.3.  Phase 3 -- Ordered Execution and Completion (Forward Wave)

   *  A node in WATCH that receives COMPLETE from its predecessor moves
      to START and begins its local task.

   *  When a node finishes its task, it moves START -> COMPLETE and:

      -  Sends COMPLETE to successor (triggers successor to start)

      -  Sends COMPLETE to predecessor (allows predecessor to exit)

   *  A node in COMPLETE that receives COMPLETE from its successor MAY
      terminate.

   Execution order is therefore strictly A -> B -> C -> ... -> N.

1.6.  Waiting in WATCH State

   The RECOMMENDED approach is *push-based*: the node simply blocks on
   read() from the predecessor's TCP socket.  When the predecessor
   finishes, it pushes COMPLETE.  An alternative approach is to poll the
   predecessor's TCP socket.

   Both approaches are compliant.

1.7.  Example Message Flow (A-B-C-D)

   RD: READY
   ST: START
   CM: COMPLETE

   A.....B.....C.....D
   |-RD->|.....|.....| Phase 1
   |.....|-RD->|.....|
   |.....|.....|-RD->|
   |.....|.....|<-ST-| Phase 2

Douglas Dohmeyer           Expires 5 June 2026                  [Page 5]
Internet-Draft                  ChainSync                  December 2025

   |.....|<-ST-|.....|
   |<-ST-|.....|.....| Phase 3
   |.....|.....|.....| A starts immediately
   |-CM->|.....|.....| A finishes and B starts
   |.....|-CM->|.....| B finishes and C starts
   |.....|.....|-CM->| C finishes and D starts
   |.....|.....|<-CM-| D finishes
   |.....|<-CM-|.....X D exits
   |<-CM-|.....X...... C exits
   |.....X............ B exits
   X.................. A exits

2.  IANA Considerations

   This memo includes no request to IANA.

3.  Security Considerations

   Connections SHOULD use TLS 1.3.  Production deployments SHOULD use
   mutual TLS with certificate pinning or pre-shared keys to prevent
   node impersonation.

4.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgements

Author's Address

   Douglas Russell Dohmeyer
   Independent Researcher
   United States of America
   Email: douglas.dohmeyer@protonmail.com

Douglas Dohmeyer           Expires 5 June 2026                  [Page 6]