Side-topic-ish: Ideally we’d have an implementation that would be for sessions, where sessions are name->address-space mappings.
HTTP is nearly that, and is thus nearly ideal for distributed systems stuff, where we can then make implementation decisions to do CAP-theorem trade-offs between consistency vs availability (partitions are not-optional) and placement. Treating it this way allows for (but doesn’t require) application semantics that are much more rich than standard non-streaming stuff, and relatively cheaply for application programmers once we get some basics implemented. For instance, users don’t care, and haven’t cared for ages, about which host terminates a request, or an upload, etc. So.. by defining name->address space mappings, we can make sessions that can be terminated by multiple hosts simultaneously (this is HTTP-layer, not QUIC-layer), which provides exponentially more reliability and simplicity for the application programmer. If you want streams-of-atoms (but still need byte-level flow control because.. without that we have OOMs and badness), you need two streams: one for the variable-size data, and stream with one fixed-size records which describes the variable-size data. Then you get distributed-systems-goodness, flexibility in application-level interactions, and a standard interface that loadbalancers/L7 routers/L7 caches can understand and provide value to. Back to the primary topic: I can see wanting to use QUIC so that one can follow whatever advancements are likely to come around CC, etc. Part of the reason QUIC is encrypted is to ensure that elements on the wire don’t become dependent on its wire format and ossify the protocol, thus preventing advancements. This, sadly, isn’t theoretical—we’ve seen this ossification delay or prevent good things from coming a number of times in TCP. -=R From: QUIC <[email protected]> on behalf of Phillip Hallam-Baker <[email protected]> Date: Friday, September 30, 2022 at 11:34 AM To: Matt Joras <[email protected]> Cc: Randy Armstrong (OPC) <[email protected]>, [email protected] <[email protected]> Subject: Re: Request for Authenticated but not Encrypted Traffic On Fri, Sep 30, 2022 at 12: 25 PM Matt Joras <matt. joras@ gmail. com> wrote: Hi, On Fri, Sep 30, 2022 at 9: 02 AM Randy Armstrong (OPC) <randy. armstrong@ opcfoundation. org> wrote: Process control is absolutely not a good match for QUIC, ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd On Fri, Sep 30, 2022 at 12:25 PM Matt Joras <[email protected]<mailto:[email protected]>> wrote: Hi, On Fri, Sep 30, 2022 at 9:02 AM Randy Armstrong (OPC) <[email protected]<mailto:[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.
