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
