Zenoh Transport and Layer 1 vs Layer 2 features

[gregmedd]

I've been looking at the Zenoh transport implementations and have some questions about the complexity therein. From what I am seeing, the implementations are handling each of the layer 2 messaging modes through different Zenoh transport mechanisms. For example, RPC requests and responses are handled through the query system. However, this seems to be going beyond what is actually required by uProtocol. Transports are only required to provide the layer 1 capabilities in the uProtocol spec - they just need to get messages sent from a source to any applicable listeners. The transport doesn't need to implement special behavior at layer 2 within a transport since layer 2 operations can be handled in transport-independent code on top of layer 1.

Additionally, in separating out transport operations based on layer 2 messaging types, several critical use cases in uProtocol (such as recording, playback, logging) won't work as expected without additional changes in the core Zenoh implementation.

Is there a particular advantage in handling each message type differently?

It seems like each sent message could simply be published to topic formed from its source / sink addresses, and registered listeners can subscribe to those topics. That would meet all of the requirements of uProtocol, and considerably reduce the complexity of the transport implementations.

[evshary]

IMHO, communication mechanism can be classified into two kinds:

1. publish - subscribe
2. request - response

In uProtocol, we have Publish and Notification message type in the first kind and Request and Response in the second kind.
In Zenoh, we have pub/sub for the first kind, and get/queryable for the second kind. The advantage of this is that we can increase the performance of handling back-and-forth messages. Instead of creating two Zenoh keys (topic) to deal with different direction connections, the mechanism can avoid this kind of overhead. That's why we have the current design.

I think this is the trade-off between complexity and performance. Maybe it's more related to how we utilize the request and response in the real scenario. If we don't expect high performance on this kind of message type, it's fine to use a simpler way to transmit data instead, which is easier for developers to understand and maintain.

Let me loop @Mallets and @sashacmc for more insightful opinions.

[evshary]

It's also worth taking how to implement the record and replay into account. I don't know who will do that implementation. Allow me to loop @PLeVasseur here since I discussed the issue with him before.
eclipse-uprotocol/up-transport-zenoh-rust#32

[gregmedd]

@evshary - I've heard this described as an optimization in many threads, but do we have any data on what the performance delta is between the two? I read through some documentation and posts discussing Zenoh performance, but they all described pub/sub as compared to Zenoh pub/sub alternatives (e.g. MQTT). From what I understand, Zenoh pub/sub is already very performant.

How big of a difference does the query (request/response) mechanism provide? Particularly given that use cases like recording and logging are trivial in pub/sub mode and unavailable with queries, it would be helpful to understand what we are gaining.

And if the gain isn't huge, maybe we could consider switching to all pub/sub for now so we can get all of the required uProtocol use cases working first, then consider optimizing after we know it works.

[PLeVasseur]

FWIW I think it's reasonable to use the pub/sub paradigm for now unless and until we really feel the need for speed ™️

At that point we can add that further sophistication.

[gregmedd]

We would also be able to build out more test coverage starting with pub/sub so that if/when we do optimize by using queries, we can validate that the code changes work in the way we need them to.

[gregmedd]

Mirroring the questions I asked on the SDV slack: Is this how we want to proceed? Should we publish PRs for the language libraries stripping out queries for alpha.4? Should I clean up this draft PR and move forward with the change?

[stevenhartley]

Switched over to issue #233. We will use Zenoh for pub/sub only for L1 transport. Once that is working well, we can consider using it for queryables as an optimization layer