API review for QUIC APIs

[scalablecory]

Placeholder for API review of QUIC APIs.

@ManickaP @CarnaViire @karelz we should try to get all the APIs designed soon. The API review will take some time (probably 4-8hr). Also mindful of any time @halter73 @jkotalik need to prove the APIs out in Kestrel.

---

Tracking API changes:

class QuicListener
{
-   public void Start(); // merged into constructor
}

class QuicStream
{
// this may be changed later after discussions; just want to be sure this change is not lost
+   public ValueTask ShutdownCompleted(CancellationToken cancellationToken = default);
}

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Placeholder for API review of QUIC APIs.

@ManickaP @CarnaViire @karelz we should try to get all the APIs designed soon. The API review will take some time (probably 4-8hr). Also mindful of any time @halter73 @jkotalik need to prove the APIs out in Kestrel.

Author:	scalablecory
Assignees:	-
Labels:	area-System.Net.Quic
Milestone:	6.0.0

[geoffkizer]

I created #44786 a while back to try to capture the existing open issues. It may be missing some issues.

That said, we need to do a review of the entire API surface.

[wegylexy]

I wish there's a way to use the underlying QUIC connection of HTTP/3 to send/receive custom datagrams, such that unreliable data may be multiplexed along the same SignalR connection. See also wegylexy#1

[mclayton7]

@wegylexy I really like the idea of adding datagram support and hope this gets in! Would it be possible to use an async method instead of an event for the datagram receive? I think this would be more in line with the async socket apis.

[mclayton7]

Looking through some of the existing QUIC implementation in Kestrel, and the work @scalablecory has done to support msquic 1.0, it would be great if the hooks were available to support a 3rd party WebTransport/QuicTransport implementation in Kestrel. I think it would just require exposing the Kestrel QUIC classes and letting someone write a thin layer to set the correct apln.

[wegylexy]

@wegylexy I really like the idea of adding datagram support and hope this gets in! Would it be possible to use an async method instead of an event for the datagram receive? I think this would be more in line with the async socket apis.

Since msquic doesn't transfer ownership of the received datagram buffer, it must be consumed synchronously (e.g. through a ReadOnlySpan<byte>) to avoid copying the buffer. As such, raising an event / callback seems to be the only option for now. A typical use case would parse the buffer quickly into another class/struct, and then that new object could be queued asynchronously.
There is also an issue with the current socket APIs for streams as the shared resettable completion source leads to undefined behavior on overlapped async operations.

[scalablecory]

@wegylexy please create a new issue with proposed API.

Note the datagram RFC has not been finished yet, so we will likely not support this in .NET 6.

[wegylexy]

msquic has changed a lot too? Session is now Configuration and the .NET 6 preview API doesn't work with v1.0.0 of msquic.dll unless I missed something.

[ManickaP]

We have a dependency on a certain msquic revision, see the git submodule here: https://github.com/dotnet/runtimelab/tree/feature/System.Net.Experimental.MsQuic/src
We do plan to update to the newer msquic version, but that's work in progress.

[wegylexy]

Significant changes since microsoft/msquic#777 but this is the first stable supported release version.

[mclayton7]

@wegylexy @scalablecory has done some work here (https://github.com/scalablecory/runtime/tree/msquic-update) on updating System.Net.Quic to work with the 1.0.0 release of msquic.