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)

[Kazuho Oku <[e-mail]>]

2024年2月23日(金) 0:42 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.
>

Thank you for sharing the use case. This is very interesting.

I think we can use QUIC on Streams as is to fulfill both the use cases, in
either of the following ways:

1. Run QUIC on Streams on top of end-to-end TLS.

The idea here is that the Relay can forward encrypted bytes of an
end-to-end TLS connection.

In the case of path 1, I think it would be possible to set up a TLS
connection between Client and Connector, on top of "TCP/TLS Connection 1"
and "TCP/TLS Connection 2"? Then, we can run QUIC on Streams on top of that
end-to-end TLS connection for multiplexing streams.

In the case of path 2, Client and Connector can establish an end-to-end TLS
connection atop of QUIC streams provided by the two hops. Then, we would
run QUIC on Streams on top of that end-to-end TLS connection.

2. Run QUIC v1 on top of unreliable multi-hop transport, each hop provided
either by QUIC v1 or QUIC on Streams.

The idea here is that the Client and the Connector would send QUIC v1
packets through the hops (i.e., "TCP/TLS connection X" and "QUIC/UDP
Connection X"). The hops or the Relay between the hops might drop the
end-to-end QUIC v1 packets, but that'd be fine as they would be
retransmitted as needed.

In the case of path 1, QUIC on Streams would be used atop each hop (i.e.,
"TCP/TLS connection 1" and 2), and the end-to-end QUIC v1 packets will be
conveyed by the DATAGRAM frames.

In the case of path 2, each hop (i.e., "QUIC/UDP Connection 1") would
convey the end-to-end QUIC v1 packets using the DATAGRAM frames.

WDYT?


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

-- 
Kazuho Oku