Re: Request for Authenticated but not Encrypted Traffic

[Matt Joras <[e-mail]>]

Hi,

On Fri, Sep 30, 2022 at 9:02 AM Randy Armstrong (OPC) <
[e-mail]> 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.

>
>
> *From:* Phillip Hallam-Baker <[e-mail]>
> *Sent:* Saturday, October 1, 2022 12:47 AM
> *To:* [e-mail]
> *Cc:* Randy Armstrong (OPC) <[e-mail]>;
> [e-mail]
> *Subject:* Re: Request for Authenticated but not Encrypted Traffic
>
>
>
>
>
>
>
> On Fri, Sep 30, 2022 at 10:58 AM Behcet Sarikaya <[e-mail]>
> wrote:
>
>
>
>
>
> On Thu, Sep 29, 2022 at 4:42 PM Randy Armstrong (OPC) <
> [e-mail]> 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.
>
>
>