* 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. From: Phillip Hallam-Baker <[email protected]> Sent: Saturday, October 1, 2022 12:47 AM To: [email protected] Cc: Randy Armstrong (OPC) <[email protected]>; [email protected] Subject: Re: Request for Authenticated but not Encrypted Traffic On Fri, Sep 30, 2022 at 10:58 AM Behcet Sarikaya <[email protected]<mailto:[email protected]>> wrote: On Thu, Sep 29, 2022 at 4:42 PM Randy Armstrong (OPC) <[email protected]<mailto:[email protected]>> wrote: At this point we have not determined that QUIC will actually be better than TCP for OT applications. That said, we see the potential because there is a need for UDP based protocols on some embedded devices because the OS does not support TCP and QUIC offers the potential for prioritizing traffic with multiple streams. There is also some effort to deploy 5G networks within factories which would mean the lower latency recovering after IP address changes could be a benefit. One risk for QUIC in this setting comes from the memory consumption needed to handle out of order/repeated messages. TCP has had decades to optimize this problem which means it could be more efficient. If the WG already knows that QUIC will not work so well on low end embedded devices then we would like to learn more about the issues. Hi Randy, I read the above. I think that TCP for IoT has been researched a lot and now we have some stripped down versions of TCP that are being used. Not sure or not familiar with anything similar for Quic. Quic is not like TCP, i.e. as far as I know, for Quic there is only one sender, that is HTTP. So you may be opening a can of worms with this proposal. Good luck, Behcet This is a very good point. I dropped out of QUIC as it became clear that 1) the WG is developing an optimized transport for Web Browsing and not a general purpose transport and 2) This is absolutely the right approach the WG should take. Further, the QUIC group should resist attempts to 'build on QUIC' and turn it into a kitchen sink protocol solving every problem. That is how specifications wear out. Web browsing is an application that is more than significant enough to justify its own transport. It is also a very complicated ecosystem with a lot of legacy commitments that have to be respected and so any solution is inevitably going to be complex. However, one of the consequences of QUIC is that there is now precedent for developing new transport protocols built on UDP and so the floodgates are open. When the Internet was originally designed in the 70s, the only way to get transport sufficiently fast to be acceptable was to run it in the kernel. That is no longer true. Modern CPUs are fast enough and modern OS agile enough to offload transport out of the kernel. 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, What we need at this point is a transport that is designed for the needs of Web Services. A transport that is designed to be transaction oriented with suitable controls for rate limitation, authentication being established between the relevant end-points, etc. etc. A transport that allows us to keep a connection open for hours or days or years without constant heartbeat messages between every pair of endpoints. In short, what we need is what the OSI stack called a presentation layer. While much of the work on QUIC would be relevant to such an effort, it should do the same as QUIC did and start from a clean sheet of paper.
