Re: [dispatch] A State Synchronization Working Group

[Michael Toomim <[e-mail]>]

(Forgot to reply all.)

Ah, yes, it is true that there is state synchronization happening within 
most stateful protocols like FTP and TCP. Let's clarify which aspects 
are within scope for this proposed Working Group.

    1. Not all state in a stateful protocol is synchronized across both
    (or all) peers. Some of it is held only in one peer. Out-of-scope is
    any aspect of the system where we don't require (1) both peers to
    hold the same state in memory over a period of time, and (2) the
    memory does not change over time while it is being held.

    2. Not all state synchronization needs a standard protocol. The WG
    would be pragmatic, like any other IETF working group. We would
    adopt work when there are multiple implementers that have a desire
    to interoperate, and when the work to generalize them appears to be
    feasible, and has volunteers willing to take it on.

So I would add to your statement of what is "useful" here:

> 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.
Although I too am inspired by the mathematical elegance of the "General 
State Synchronization" problem, this WG would need to be pragmatic, and 
its definition for "useful" would have to include multiple implementers 
finding value in interoperability for real use-cases.

We can apply this to the TCP example. Perhaps there's value in 
generalizing TCP's method of synchronizing connection state (e.g. 
LISTENING/ESTABLISHED/CLOSED/SHUTDOWN) with other protocols for other 
things. If someone can persuade multiple implementers of that value, 
that would make a case for the WG to adopt this work.

That shouldn't be a blocker for us to generalize other simpler or 
clearer use-cases, though.

I think there is already clear attainable value in generalizing the 
state synchronization protocols in SCIM, IPP, NETCONF, SIP, JMAP, and 
most modern (dynamic) web apps. These do very similar types of state 
sync, over HTTP, and would benefit from performance improvements, 
network robustness, and standard tooling.

On 10/27/23 8:38 AM, Joe Touch wrote:
> 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 <[e-mail]> 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
>>