External datagram I/O for the connection state machine

[kingsznhone]

Describe the feature you'd like supported

I would like to request a public API that lets an MsQuic connection state machine be driven by datagrams supplied by the application, similar in spirit to what quinn-proto enables.

Motivation

The use case is a relay transport where QUIC packets are carried inside another protocol, for example WebSocket relay datagrams. The relay does not terminate QUIC. It only forwards opaque packet bytes between peers.

The important requirement is that externally supplied handshake packets should be able to advance the normal MsQuic connection state machine. For example, if the application receives a peer's QUIC Initial packet from a relay, it should be able to inject that packet into MsQuic, let MsQuic process the handshake, and receive the response packet bytes that need to be sent back through the relay.

After the handshake completes, the result should be a normal MsQuic connection with streams, DATAGRAM support if negotiated, flow control, congestion control, timers, and path management still owned by MsQuic.

This is different from the QUIC DATAGRAM extension. DatagramSend sends application datagrams after a QUIC connection already exists. The requested API is lower level: it would allow the Initial, Handshake, 0-RTT, 1-RTT, ACK, and path-management packets themselves to be received from and sent to an application-owned datagram transport.

The goal is not to replace MsQuic's QUIC/TLS/stream implementation. The goal is only to let applications provide the packet transport below the QUIC state machine.

In other words, the request is not for the application to mark a connection as handshaken or construct a connection state manually. The request is for external packet I/O that can drive the existing MsQuic handshake and connection state transitions until the connection is ready for normal use.

Is this kind of external datagram I/O within the intended scope of MsQuic?

Additional context

No response

[guhetier]

Hi, the short answer is that is the short/medim term, MsQuic cannot support this. In the long term, maybe.

MsQuic architecture doesn't expose the datapath (our name for what you call the packet transport below the QUIC state machine) to the application. The original design aimed to abstract that complexity and only expose QUIC level verbs.

With more recent evolution (XDP, QMUX...) , we want more flexibility in how we handle different datapath, with as a north start, allowing an application to provide its own datapath and work queues.
But we cannot give any ETA or even if this will actually happen.

[kingsznhone]

Hi, the short answer is that is the short/medim term, MsQuic cannot support this. In the long term, maybe.

MsQuic architecture doesn't expose the datapath (our name for what you call the packet transport below the QUIC state machine) to the application. The original design aimed to abstract that complexity and only expose QUIC level verbs.

With more recent evolution (XDP, QMUX...) , we want more flexibility in how we handle different datapath, with as a north start, allowing an application to provide its own datapath and work queues. But we cannot give any ETA or even if this will actually happen.

Thank you very much for your reply. I understand that making major changes to expose the low level datapath in a foundational library like this presents significant challenges. I hope to see the day when this feature is eventually implemented.