RFC: Open and closed interactions for FIDL

[Pascal]

From the summary of Open and closed interactions for FIDL:

We introduce open interactions and closed interactions to the FIDL
language. An open interaction, even when unknown, can gracefully be handled by a
peer. An unknown closed interaction leads to abrupt termination.

[Pascal]

This RFC has been simplified, and more explanation has been added. It's also now renamed to "Handling unknown interactions" which is descriptive of what this RFC intends to improve, rather than describing the mechanism introduced. Many thanks to all the reviewers so far, and the help on clarifying things.

One open debate that is ongoing, which could benefit from an e-mail back & forth here:

Is there a need for a client to indicate to a peer that a one way interaction (i.e. event or fire-and-forget call) is so important that communication should abort if the interaction is unknown?

The alternative simplifies the design, but does not make it possible for a one way interaction to provide assurance that both peers communicating know about it. My worry is that this will lead to resorting to method calls returning an "ack" (likely an empty struct), solely for ensuring that peers are in sync.

[Adam Barth]

On Thu, Oct 7, 2021 at 2:31 PM 'Pascal' via eng-council-discuss <eng-counc...@fuchsia.dev> wrote:

This RFC has been simplified, and more explanation has been added. It's also now renamed to "Handling unknown interactions" which is descriptive of what this RFC intends to improve, rather than describing the mechanism introduced. Many thanks to all the reviewers so far, and the help on clarifying things.

One open debate that is ongoing, which could benefit from an e-mail back & forth here:

Is there a need for a client to indicate to a peer that a one way interaction (i.e. event or fire-and-forget call) is so important that communication should abort if the interaction is unknown?

The alternative simplifies the design, but does not make it possible for a one way interaction to provide assurance that both peers communicating know about it. My worry is that this will lead to resorting to method calls returning an "ack" (likely an empty struct), solely for ensuring that peers are in sync.

Keep in mind that one-way messages over channels are always best-effort.  In general, there's no way for the sender to know that the peer received the message other than to have an acknowledgement, either of the message itself or via a larger "commit" operation.  For that reason, I would be surprised that a message would be sufficiently "important" to require the peer to close the connection if the message is not understood but also not "important" enough to require acknowledgement in some way.

It's also worth saying that we plan to use FIDL protocols in the context of platform versioning, which makes it easier for the sender to predict whether the peer can understand the message.  If the sender gets any response from the peer that falls within the availability range of the one-way message, then the sender can reasonably conclude that the peer will understand the one-way message.

Adam

On Thu, Sep 16, 2021 at 3:30 PM Pascal <pasca...@google.com> wrote:

From the summary of Open and closed interactions for FIDL:

We introduce open interactions and closed interactions to the FIDL
language. An open interaction, even when unknown, can gracefully be handled by a
peer. An unknown closed interaction leads to abrupt termination.

--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "eng-council-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eng-council-dis...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/eng-council-discuss/CAHKqeVHDN%2BkUikSmwZeC9AVtgs_ss%2BfU9%3DHXGxOStraGVr0KnQ%40mail.gmail.com.

[Pascal]

This RFC has been simplified, and more explanation has been added. It's also now renamed to "Handling unknown interactions" which is descriptive of what this RFC intends to improve, rather than describing the mechanism introduced. Many thanks to all the reviewers so far, and the help on clarifying things.

One open debate that is ongoing, which could benefit from an e-mail back & forth here:

Is there a need for a client to indicate to a peer that a one way interaction (i.e. event or fire-and-forget call) is so important that communication should abort if the interaction is unknown?

The alternative simplifies the design, but does not make it possible for a one way interaction to provide assurance that both peers communicating know about it. My worry is that this will lead to resorting to method calls returning an "ack" (likely an empty struct), solely for ensuring that peers are in sync.

Keep in mind that one-way messages over channels are always best-effort.  In general, there's no way for the sender to know that the peer received the message other than to have an acknowledgement, either of the message itself or via a larger "commit" operation.  For that reason, I would be surprised that a message would be sufficiently "important" to require the peer to close the connection if the message is not understood but also not "important" enough to require acknowledgement in some way.

The scenario that I have in mind is more sequencing of messages, such as "DoX(), DoY(), ActivateImportantThing(), DoZ(), DisableImportantThing(), DoX()". Because we guarantee message ordering, we provide a guarantee that DoZ() is bracketed by ActivateImportantThing / DisableImportantThing. Relying on acknowledgments means we lose pipelining benefits.

 

It's also worth saying that we plan to use FIDL protocols in the context of platform versioning, which makes it easier for the sender to predict whether the peer can understand the message.  If the sender gets any response from the peer that falls within the availability range of the one-way message, then the sender can reasonably conclude that the peer will understand the one-way message.

While that's true, a case where the two peers must discover each other's ABI falls in the protocol negotiation world, and appropriate for some things, but not others. The evolution mechanisms described in this RFC are what i would call "local evolution" whereas I tend to think of protocol negotiation as providing "global evolution". Both are needed, but one does not replace the other.

PL

[Adam Barth]

On Sat, Oct 9, 2021 at 10:41 AM Pascal <pasca...@google.com> wrote:

This RFC has been simplified, and more explanation has been added. It's also now renamed to "Handling unknown interactions" which is descriptive of what this RFC intends to improve, rather than describing the mechanism introduced. Many thanks to all the reviewers so far, and the help on clarifying things.

One open debate that is ongoing, which could benefit from an e-mail back & forth here:

Is there a need for a client to indicate to a peer that a one way interaction (i.e. event or fire-and-forget call) is so important that communication should abort if the interaction is unknown?

The alternative simplifies the design, but does not make it possible for a one way interaction to provide assurance that both peers communicating know about it. My worry is that this will lead to resorting to method calls returning an "ack" (likely an empty struct), solely for ensuring that peers are in sync.

Keep in mind that one-way messages over channels are always best-effort.  In general, there's no way for the sender to know that the peer received the message other than to have an acknowledgement, either of the message itself or via a larger "commit" operation.  For that reason, I would be surprised that a message would be sufficiently "important" to require the peer to close the connection if the message is not understood but also not "important" enough to require acknowledgement in some way.

The scenario that I have in mind is more sequencing of messages, such as "DoX(), DoY(), ActivateImportantThing(), DoZ(), DisableImportantThing(), DoX()". Because we guarantee message ordering, we provide a guarantee that DoZ() is bracketed by ActivateImportantThing / DisableImportantThing. Relying on acknowledgments means we lose pipelining benefits.

Yep, I can see that scenario benefiting from a one-way "must understand" bit.

 

It's also worth saying that we plan to use FIDL protocols in the context of platform versioning, which makes it easier for the sender to predict whether the peer can understand the message.  If the sender gets any response from the peer that falls within the availability range of the one-way message, then the sender can reasonably conclude that the peer will understand the one-way message.

While that's true, a case where the two peers must discover each other's ABI falls in the protocol negotiation world, and appropriate for some things, but not others. The evolution mechanisms described in this RFC are what i would call "local evolution" whereas I tend to think of protocol negotiation as providing "global evolution". Both are needed, but one does not replace the other.

Oh, I definitely think both kinds of evolution are needed.  I brought it up because they can work in concert.  In your example above, suppose that ActivateImportantThing/DoZ/DisableImportantThing were all introduced at the same API level.  The sender can reasonably conclude (assuming we handle deprecation consistently) that a receiver who understands DoZ will also understand ActivateImportantThing and DisableImportantThing.

It's hard to give more concrete advice without knowing more about how much complexity supporting these scenarios involve.  I'm happy to read the draft RFC in detail if that would be helpful.

Adam

[Pascal]

I'd like to ask for this RFC to move to last call: all reviewers have +1'ed.

[Adam Barth]

Done!

--

All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "eng-council-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eng-council-dis...@fuchsia.dev.

To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/eng-council-discuss/CAHKqeVFkBwYRCMjyNuxaJryob1SCBvYkgnQ%3D7sP0b95uGpOXQQ%40mail.gmail.com.