Re: [dispatch] A State Synchronization Working Group

Joe Touch <touch@strayalpha.com> Fri, 27 October 2023 15:39 UTC

Return-Path: <touch@strayalpha.com>
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 2D608C15109C for <dispatch@ietfa.amsl.com>; Fri, 27 Oct 2023 08:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.625
X-Spam-Level:
X-Spam-Status: No, score=-3.625 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_PSBL=2.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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=strayalpha.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 KtNY3F7oThtD for <dispatch@ietfa.amsl.com>; Fri, 27 Oct 2023 08:39:11 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0EA8C14EB19 for <dispatch@ietf.org>; Fri, 27 Oct 2023 08:39:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0dkC/bgDGwaOHaKj3e8zIps4VQjODrYjrp+y5Q/RSLY=; b=xgLxMjBtghyF3ZcPF567fFw6As WIcAZqrlsfXkb+ynJHTaTFpvOX+XGp+WMWxGYXdESKEhIphZDsh4WvZ+feJrDgQyGr+xYRbaQ1NrT 0F8YNK+qAlx46WUL4ljgb+FO+giP3iTbCOmwlgy2orHtvTP/hQ3HBc8JMtROL9SrQExihqEukoVe7 7xJlai2UQticd1nHHyawf7mNwxU7fybekRpD3ts5g9A+y+G5V2MARss0iK/1TC8eaMwM2vZMc+GTA QbhOVgtP2e3i8iH48SN9Trs1SRJkdl5Dus/BR+Wunqx8t+GZj6guH0LIiDc0XEZVaKmALSTG3z4fi cPoZimKQ==;
Received: from 096-040-160-173.res.spectrum.com ([96.40.160.173]:57430 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.1) (envelope-from <touch@strayalpha.com>) id 1qwOvS-00DNdW-0Q; Fri, 27 Oct 2023 11:39:10 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail-46977590-9693-48D2-BC6F-DEE6892E50A2"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <bf9a894c-8540-6679-e3c4-85902581f773@gmail.com>
Date: Fri, 27 Oct 2023 08:38:54 -0700
Cc: dispatch@ietf.org
Message-Id: <57ED1C14-DC52-409B-BFD4-EB6D4D4154EA@strayalpha.com>
References: <bf9a894c-8540-6679-e3c4-85902581f773@gmail.com>
To: Michael Toomim <toomim@gmail.com>
X-Mailer: iPad Mail (21B74)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/3LdPzOZhFRVAOnJ3Did4ievHMmM>
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 <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Oct 2023 15:39:16 -0000

Stateful protocols synchronize state. Not all sync is persistent or fault-recovering. 

TCP synchronizes its state, the state of its options, as well as the information about its segments. Some of these are one-shot events; others have their shared state maintained.

FTP relies on the state of TCP for its own basic state (connected or not) and to perform transfers, but - as you note, the transfer part is one-time.

The challenge appears to be defining useful mechanisms that aren’t domain specific. I.e., rsync is a file and directory state sync protocol already. And by useful, IMO that would mean being a resource in which the stateful parts of existing protocols could be represented or implemented too.

Joe

> On Oct 26, 2023, at 3:40 PM, Michael Toomim <toomim@gmail.com> wrote:
> 
> 
> Joe Touch wrote:
>> Hi, Michael,
>> 
>> How is this not exactly what all stateful protocols all already do?
> Sure! Let's distinguish a stateful protocol from a state synchronization protocol, because these are totally different things.
> 
> First, not all stateful protocols do synchronization. Consider the stateful protocol FTP:
> 
> $ ftp exmaple.com
> ...
> cwd docs
> mkd ietf-2023
> cwd ietf-2023
> These commands change the server state, but don't affect the client state. The client doesn't know what the current working directory is, nor what's on the server's filesystem.
> 
> A state synchronization protocol ensures (or tries to ensure) that both peers end up with the same state. For instance, a FTP client can download a file from a server:
> 
> get braid-http.txt
> ...but if the file changes on the server, FTP has no mechanism to automatically update the client. And if the file changes on the client, FTP does not automatically update the server. And if both client and server change the file simultaneously, FTP has no way to automatically merge those edits. And if the connection dies, FTP does not automatically re-establish the connection and the current working directory—the user has to do all of this manually. Thus, FTP is a state transfer protocol, not a state synchronization protocol, and it happens to do this statefully.
> 
> As a rule of thumb, state synchronization protocols tend to have one or more of these keywords in them:
> 
> - Publish / Subscribe
> - Notify / Notification
> - Event, Event Types, State, Updates
> - Diffs, Patches, Merges
> - Synchronization
> 
> See https://www.rfc-editor.org/rfc/rfc4533.html for an example that is currently open in a browser tab on my computer.
> 
> Michael