Re: [dispatch] A State Synchronization Working Group

[Michael Toomim <[e-mail]>]

Excellent prompt, Dale. Thank you! Our minds are on the same path, and I 
can address your questions directly.

The group would, indeed, produce *abstract* protocols for general models 
at useful-but-limited scopes of state synchronization. Our Braid group 
has begun work on an abstract protocol here: 
https://github.com/braid-org/braid-spec/issues/124. However, we chose to 
focus our initial specification efforts on the concrete 
draft-toomim-httpbis-braid-http first, so you should read that—the 
abstraction should still be evident.

The key question for IETF vs. IRTF is whether we have a known model & 
scope that is sufficiently general and ready to standardize, or whether 
further research is needed before we can begin standardization in earnest.

I claim the model in draft-toomim-httpbis-braid-http *is* sufficient for 
a useful (and purposefully limited) scope of synchronization, and is 
ready for standardization. We are bringing it to HTTPbis attention for 
this reason (email thread forthcoming). It has been tested, with a 
variety of implementations, for a few years—resulting in only minor 
adjustments.

Now, you are right to notice that the topics we've researched are *not 
all* ready for standardization. It will probably help to organize these 
topics into multiple categories—those ready, those almost ready, and 
those that still need deep research. Here is my thinking:

*1. Ready for Standardization*

These four aspects are currently specified in 
draft-toomim-httpbis-braid-http [1], and are ready for standardization:

 1. General History & Versioning
 2. General Subscription & Update semantics
 3. General Mutation Language—for the class of "replace range X with
    contents Y" operations
 4. General Merging & Consistency specification semantics

I claim that anything you want to do with history, mutations, 
subscriptions, or merging can be done in the Braid-HTTP abstract model. 
Our group has deliberated, specified, implemented, and tested this 
against multiple concrete systems. For instance:

  * We have implemented babelfishes that successfully convert network
    messages from multiple CRDT/OT systems (automerge, yjs, sync9,
    shelf, diamond-types) into and out of this general protocol [2],
    [3], [4]
  * We have demonstrated high performance with this model:
      o We built the world's fastest text CRDT on this protocol [5]
      o We proved the model can be extended for history pruning [6]

*2. On-Deck: What's Next*

We have complete research on the following aspects of general State 
Sync, but they have not yet been tested against multiple real systems, 
nor has anyone authored specifications of them to open feedback and 
deliberation:

 1. Synchronized Live Queries (e.g. GraphQL) over data
 2. Acknowledgement & Validation of Distributed Mutations
 3. General Mutation Language—for the class of Clone, Move, Wrap, and
    Unwrap operations
 4. BFT-resiliant Mutation messages

*3. Not Ready for Standardization*

The Braid group has been an audience for research on these topics, but 
AFAIK there is no general "known solution" yet:

 1. P2P identity, authentication, transport, and naming
 2. Synchronizing peers through schema evolution
 3. Low-level networking state— e.g. BGP, routing tables, IP header
    compression, TCP link state
 4. Interoperable Programming API
 5. Kernel API for Multi-Process state in Operating Systems

Section (1) is ready for standardization, and is the reason to form a 
IETF WG. The group's immediate work would be to map this general model 
to existing protocols and applications, to simplify their specification, 
implementation, and provide them with improved performance and 
networking robustness.

Sections (2) would require an explicit proposal and call-for-adoption 
before the WG takes it on for standardization.

Section (3) is out-of-scope for standardization. However, the group 
would benefit as a venue to present, discuss, and connect these research 
ideas to the real needs of implementers, and give them the feedback and 
critique necessary to generalize into potential standard solutions.

The core dilemma is that section (1) needs a IETF WG, but section (3) 
could be a IRTF RG.

Here are some options for how to proceed:

 1. Create a IETF WG, that also provides a forum to hear new research ideas
 2. Create a IRTF RG, and give up on making standards
 3. Create /both/ a IETF WG and a IRTF RG and split attention between
    two groups and two administrations
 4. Ask the administration to make an exception, and list a single group
    across both IETF and IRTF organizations

What do you guys think is the best option here?

Michael

/Links:/
[1] https://datatracker.ietf.org/doc/html/draft-toomim-httpbis-braid-http-03
[2] https://braid.org/automerge
[3] https://braid.org/demo/interoperate
[4] https://braid.org/algorithms/shelf
[5] https://josephg.com/blog/crdts-go-brrr/
[6] https://braid.org/antimatter

Dale R. Worley wrote:
> I can conceive that a State Synchronization Working Group could define
> an abstract sync protocol, which each networking protocol would then
> implement in a straightforward way suitable for its structure.
>
> But this would have some prerequisites.  The basic one is to believe
> that this is work for the IETF rather than the IRTF:  Write a convincing
> exposition that, relative to a sufficiently general model of "state",
> people have produced a sufficiently efficient (and comprehensible)
> general synchronization protocol.
>
> In particular, the long list of research results you give *decreases* my
> confidence in the current state of the art -- problems that generate a
> lot of papers are generally ones that don't yet have a "known solution".
>
> What I want to see is a (short) list of documents, which you think if I
> read them, I will be convinced that creating a standardized sync
> protocol is an attainable engineering task.  E.g. one response would be
> "Please read the Braid draft, draft-toomim-httpbis-braid-http, it covers
> everything you could possibly want to know!"
>
> Dale