See RFC 9250 for an example of transaction based application using QUIC. -- Christian Huitema
> On Sep 30, 2022, at 12:33 PM, Phillip Hallam-Baker <[email protected]> > wrote: > > > > >> On Fri, Sep 30, 2022 at 12:25 PM Matt Joras <[email protected]> wrote: >> Hi, >> >>> On Fri, Sep 30, 2022 at 9:02 AM Randy Armstrong (OPC) >>> <[email protected]> wrote: >>> Process control is absolutely not a good match for QUIC, nor are Web >>> services in general. HTTP is a lousy transport for Web Services and I write >>> as one of the people who designed HTTP/1.0, >>> >>> >>> Can you explain what aspects of QUIC make it not suitable? >>> >>> I thought a QUIC stream was a full duplex TCP-like pipe between two >>> processes. >>> >>> But your description makes it sound like it is as limited as a HTTP >>> connection. >>> >> >> While Phil's individual participation may have left him with such an >> impression, this is not manifest in the protocol that was standardized nor >> the implementations that have materialized. QUIC is certainly not limited to >> the semantics of HTTP, and has many desirable properties that make it a very >> flexible "generic" transport protocol. While HTTP traffic on the Internet >> was a driving usecase for implementers and was the first usecase >> standardized, it is certainly not the only appropriate usecase. Indeed, >> there are already non-HTTP and non-Internet users of QUIC at scale. >> >> The QUIC WG is a venue to discuss how QUIC can be extended to meet emerging >> needs application usecases, though of course it is not the case that QUIC is >> the only (or best) potential solution to applications' needs for >> transporting bits of data over networks. > > The crux of the matter is that the high level model of QUIC is that it > provides a collection of streams between two points. While that is what > people are used to using in WebServices, this model is really only suited to > Web Services that are inherently data retrieval. > > What Web Services really need is a mechanism that is purpose designed to > support transactional interactions and expose certain information to the > service provider and service consumer that really doesn't fit the HTTP model > at all well. > > [Yes, I know the holy writ of Thompson and Richie proved that everything is a > stream... No they didn't and I discussed this with Richie personally. As with > much of what is attributed to David Clarke, do not extrapolate conclusions > beyond the context in which they were developed without thought.] > > What we are doing today is using HTTP POST as a presentation layer on top of > TCP, TLS or QUIC. And that approach has limitations that really can't be > addressed within the HTTP framework which is RPC Request/Response. For a > robust transactional system, I want to be able to do more than simple > subordination. I want to allow a service to receive a series of transaction > requests and then report back results on each part as they are completed. I > want to be able to report back partial results. I want a service to be able > to decide whether it wants to accept a transaction request requiring a large > amount of data to be operated on before the data is sent. > > Yes, for people who have only seen Web Services built on HTTP, this is going > to raise the question, 'why do we need to do this'. > > The way forward in this case is to build something that is purpose designed > to support Web Services (and not Web Browsing) and then see if it makes sense > to backport the same capabilities into QUIC. Which it might or might not. The > problem from my end being that QUIC is already a very large and very complex > specification and we might only end up using a small part of that. >
