Re: Request for Authenticated but not Encrypted Traffic

[Willy Tarreau <[e-mail]>]

On Fri, Sep 30, 2022 at 02:34:11PM -0400, Phillip Hallam-Baker wrote:
> 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.

Why ? I mean, there was a considerable effort so split gQUIC into QUIC+H3,
and QUIC does provide independent, full-duplex streams that have nothing
to do with H3. For example, these streams could pretty well be used to
transport SSH channels and would instantly remove the fairness problems
we all know that affect SSH when one session retrieves lots of data (e.g.
scp) while another one is trying to perform interactive operations, or
the problem of window-over-window that makes the protocol totally unusable
over a slightly lossy TCP link. And that's just one use case, it can make
sense for a wide variety of applications to be able to establish an
authenticated connection, and transport information both ways, with flow
control and congestion control, interleaved with information/control
messages in the form of frames of a different type.

> 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.

Some applications use gRPC, which (ab)uses HTTP/2 for its ability to
exchange bidirectional frames, abort a transfer without giving up the
connection, etc. It seems to address many of the problems that were
not handled in the request-response model that was originally seen
over HTTP. I don't know if that solves everything, not being a web
service user myself, but it seems to respond better to your requirement
of transactions, bidirectional transfers and status info. From what
I remember, I don't see anything there that couldn't be more easily
and efficiently moved to H3 or even to QUIC thanks to the ability to
transport frames without them having to be HTTP.

> 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.

I think that the split into H3+QUIC makes QUIC much less tainted for
Web browsing than it originally was.

> 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.

For sure, web services could use a stripped down version of it, but
we all know that this approach does not scale: it starts inside the
DC between local applications, which serves as a justification for
simplifying the protocol (e.g. consider that losses are inexistent
and always imply congestion, remove support for client address
migration etc), but suddenly some users will move it outside of the
DC to connect with partners, and suddenly all of this needs to come
back with the full protocol support.

Interestingly, the one thing that could make QUIC unfit for web
services actually is its use of UDP which a lot of DC operators do
not want to see at all in the DC and are proud of being able to block
at the edge as it's extremely difficult to fight DDoS and to make sure
that your DC will not be a source of DDoS when UDP is opened at an era
where it's easy to get 10Gbps connectivity for $1/hour or less. But this
exact same property is the one that makes QUIC appealing to other users,
possibly even some hoping to use it in such DCs. It will take some time
to see if QUIC becomes popular enough to change such approaches, or if
on the opposite it brings enough trouble with it that it encourages
others to join the "no UDP there" band. Given that web services tend to
move much slower than web browsing, such users might want to observe
how it goes before deciding to generalize QUIC.

Willy