*   That is pretty much the only model we have been using but it isn't the 
only model and it is a straightjacket.

We have other protocols for publish-subscribe patterns (including multicast). 
We would not want to use QUIC for those use cases. QUIC only makes sense for 
request-response.

From: Phillip Hallam-Baker <[email protected]>
Sent: Saturday, October 1, 2022 10:18 AM
To: Christian Huitema <[email protected]>
Cc: Randy Armstrong (OPC) <[email protected]>; [email protected]
Subject: Re: Request for Authenticated but not Encrypted Traffic

Both of you are assuming a request/response paradigm.

That is pretty much the only model we have been using but it isn't the only 
model and it is a straightjacket.

On Fri, Sep 30, 2022 at 7:44 PM Christian Huitema 
<[email protected]<mailto:[email protected]>> wrote:

On 9/30/2022 4:30 PM, Randy Armstrong (OPC) wrote:
>    *   Sure, we could design a presentation layer on top of QUIC. I think it 
> is better to design a transport/presentation layer for the problem space and 
> then see how we might make use of QUIC.
>
> Not quite sure why you make a big deal about this. OPC UA supports the kinds 
> of operations you described but the complex operations are broken into 
> multiple request-response pairs for transport. All OPC UA needs is a full 
> duplex channel that allows responses to be returned in any order. I would 
> imagine that any other protocol built on QUIC would do the same.
That's exactly the way DNS over QUIC is designed. Full duplex channel
(QUIC connection) allowing for series of transactions. Each transaction
request (from the client) is mapped to a new duplex stream stream;
response come back on the reverse part of that stream; responses to
transactions arrive in any order.
> The important question is: does QUIC have any inherent limitations that would 
> make it difficult to implement complex operations over top of QUIC?

No.

You have to pay attention to the management of connections, how to
resume connections after they break, etc. But that's pretty standard
when designing a distributed application.

-- Christian Huitema

Reply via email to