Re: Proposal Towards Universal HTTP/3, with a polyfill of QUIC for TCP (Fwd: New Version Notification for draft-kazuho-httpbis-http3-on-streams-00.txt)

[Dmitry Adamushka <[e-mail]>]

Hi Kazuho,


> I am interested in what constraints this use-case introduces to QUIC on
> Streams. Am I correct to understand that your interest in forwarding the
> stream-related frames of QUIC (and possibly also DATAGRAM frames) through
> multiple hops, with each hop being either QUIC v1 (UDP) or QUIC on Streams
> (TCP)?
>

Yes, but there is more to it. And as you suggested, I'm also sharing our
use cases with the mailing list. If nothing else, maybe some people will
find them interesting or entertaining.

In principle, it looks like QUIC on Streams takes just the
streams/multiplexing part of QUIC and runs it on TCP/TLS-like transports.
Our use case seems to require 'QUIC on Streams' + 'QUIC v1 crypto'. I
wonder whether it is so extremely unusual or not. Let me elaborate.

QUIC on Streams is designed to work on top of transports that provide the 4
capabilities listed in 3.1.
<https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams#section-3.1>Properties
of Underlying Transpor
<https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams#name-properties-of-underlying-tr>
t.
For QUIC v1, the underlying transport is plain UDP, which doesn't provide
any of these 4 capabilities.

Thus, it's either all four or none, which prompts the question: are there
any useful transports* that possess only a subset of these capabilities?

We want end-to-end Client<->Connector QUIC connections (which represent
secure tunnels) between Clients and Connectors. The streams of these QUIC
connections carry the payload of the user's TCP (transparently terminated
by our proxy on the Client side) or UDP flows. Both Clients and Connectors
are transport-layer proxies.


[image: design2(5).png]
Path 3 is the classical QUIC v1.
Path 4 is addressed by QUIC on Streams.
Paths 1 and 2 consist of multiple transports, each possessing all four
capabilities. However, as a whole, these paths lack 'Confidentiality and
Integrity' because of the presence of Relay.

For Paths 1 and 2, we would need something like 'QUIC on Streams' + 'QUIC
v1 crypto'. It would need to start with a TLS handshake similar to regular
QUIC v1. Then, its behavior might resemble QUIC on Streams, but with QUIC
frames likely embedded into QUIC packets -- providing cryptographic
functions but no reliable delivery, congestion control, or other QUIC v1
services.

There is another possibility for using Path 2 with QUIC v1. Path 2 is
special because it can either possess three capabilities
(in-order-delivery, reliable-delivery, congestion-control) or only
(congestion-control*) when QUIC DATAGRAMs are used for tunneling. On one
hand, if we intend to tunnel QUIC packets through this path, congestion
control may be redundant here (which is anyway the case with some QUIC
implementations). On the other hand, it might be preferable to keep
congestion control enabled on these two connections but disable it on the
end-to-end QUIC connection.

Now, another outrageous question: Would it be useful to have Multipath QUIC
running simultaneously on top of UDP and TCP/TLS at least? The ideal case
for us is to have a single QUIC connection (secure tunnel) working on top
of all these paths above.

One of the user use cases is to allow uninterrupted migration of user
flows, say, SSH sessions, between network paths. For example, an SSH
session starts through a Relay (Path 1 or 2) and later switches to a
peer-to-peer path (Path 3) once it becomes available.

Kind regards,
Dmitry