From toomim@gmail.com Fri Oct 27 17:47:55 2023 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E2FC1519A6 for ; Fri, 27 Oct 2023 17:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.091, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGbjSPi8JZXi for ; Fri, 27 Oct 2023 17:47:51 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98907C1519A3 for ; Fri, 27 Oct 2023 17:47:51 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1c434c33ec0so22926645ad.3 for ; Fri, 27 Oct 2023 17:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698454071; x=1699058871; darn=ietf.org; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=jxR2HHrTk2EXlTsa1gga1nGx48xoa7ns0H4Y4aPgtDg=; b=bemqORi5voWLfOoY7ZlCe+dIU74GsWQabKlbA6GHYCUO9kJM3JiqfXCjm+g+u71H0D GPoQh2JauqwKZGxtG63osWJ3ImTuijUvcKPmKUwbyOLPZPPGzURMAwhxT8AapP342q+0 Vd0/BEwbi1cmMP41ckaUK32VN7jgAGygh35c62OOSsLlZZuNSWVSqzXUoSXNwOUjd9Mx Ya7UAcjwckDHsbvico1wTxjs3jf3Rk1FQBWVf7pVLIrYpLYE05RQPjsrDxeL64ehTwQl Fd+wxnO+8uVrd8OQkfSrVEgs8A/KOPUfqISsAO/bRkmzWr94Rcw4Ajai0pJiZBdnVJI4 3qLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698454071; x=1699058871; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=jxR2HHrTk2EXlTsa1gga1nGx48xoa7ns0H4Y4aPgtDg=; b=ICU4zUkDhosZGHCq5g+IR8uB+oCqDUBGkCvHZ+fv6fGZPrMc8TTJsWlk/EesSa9s0x aJKUPFhWoch5Pvdgr7r794xgHl0e66/TCwYFGZ6A8cAkRAZ7GtQqlmyKxngspDeSyhmb u3qiUHOuprLoJrBYqqfSZBdwx5iPqnKDvexVtlvaiKdzZnHL7O4PrM+0TaT/PKtKRmzH ZM3Fg+JhD+0F0thJJnPqMmXo3mCF7x0mbkS9IPFJ30PjRjNr/iSM9kDQZWs/3ntmdVFl gpb6GKAVpmQjL8h97JLlxpFvJagtpFp6gmFgKDDTWfSqG0jQaKft99/8wIzSdVpANYA4 3x/w== X-Gm-Message-State: AOJu0Yy3GBTHFHb5IiBHbPHvgitdQ6DhFsoG36V4RiJ7RoDmbHOZY9Wd az+iw3Dfm+PcOnhfKGLNLDMgKQP56Ko= X-Google-Smtp-Source: AGHT+IE8TYAYMbhuZi+rRZkQLm2y1FWCo767PR/7N/38+j+V0cS5hc8a2eX+XTK9K2QMCEKuHARTTA== X-Received: by 2002:a17:902:904a:b0:1ca:a290:4c0c with SMTP id w10-20020a170902904a00b001caa2904c0cmr3943326plz.16.1698454070840; Fri, 27 Oct 2023 17:47:50 -0700 (PDT) Received: from ?IPV6:2600:380:4527:1adf:78be:65bb:64e7:8322? ([2600:380:4527:1adf:78be:65bb:64e7:8322]) by smtp.gmail.com with ESMTPSA id b13-20020a170902650d00b001c736b0037fsm2205995plk.231.2023.10.27.17.47.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Oct 2023 17:47:50 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------Kskvw72tG51hUe14NdILe4lk" Message-ID: <39d6318e-9a55-d5f1-f45f-4650a445bdba@gmail.com> Date: Fri, 27 Oct 2023 17:47:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Content-Language: en-US To: "Dale R. Worley" Cc: dispatch@ietf.org References: <87a5s4hol8.fsf@hobgoblin.ariadne.com> From: Michael Toomim In-Reply-To: <87a5s4hol8.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [dispatch] A State Synchronization Working Group X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2023 00:47:55 -0000 This is a multi-part message in MIME format. --------------Kskvw72tG51hUe14NdILe4lk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------Kskvw72tG51hUe14NdILe4lk Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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:
    • We built the world's fastest text CRDT on this protocol [5]
    • 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
--------------Kskvw72tG51hUe14NdILe4lk--