[feature-request] Full managed Quic implement

[John0King]

Current dotnet rely on a native binary "MsQuic" , and it seems a pain dependency in some platform , such as "android".
Please consider implement a full managed quic library instead of rely on a native binary!

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

Issue Details

---

Current dotnet rely on a native binary "MsQuic" , and it seems a pain dependency in some platform , such as "android".
Please consider implement a full managed quic library instead of rely on a native binary!

Author:	John0King
Assignees:	-
Labels:	untriaged, area-System.Net.Quic
Milestone:	-

[huoyaoyuan]

See the experiment at https://github.com/dotnet/runtimelab/tree/feature/ManagedQuic

[John0King]

@huoyaoyuan the lastest comment on managedQuic was 2 years befor , and it seem been cut off because a decision to use "MsQuic" c++ binary instead of re-implement new one.
I'm wonder that does the managed quic still on the future plan ?

[rzikm]

@John0King I was the one to implement the original ManagedQuic experiment before joining the .NET networking team (it was a topic for my Master thesis). Recently, me and some other team members did a hackathon and refreshed the implementation. A more recent version is available at https://github.com/rzikm/dotnet-runtime/tree/managed-quic, but it is far from production ready.

The big technical problem preventing us/me from finishing the implementation is availability of TLS API. QUIC uses TLS 1.3 in a different way than your average TCP connection and needs access to raw (unencrypted) TLS records + encryption secrets to perform its own encryption scheme. The necessary API has been added to SChannel on Windows, but there is no such API available on Linux or MacOs (and I doubt it is present in Android APIs).

MsQuic is able to work on Linux because it is statically linking against a forked version of OpenSSL (see https://github.com/quictls/openssl). But this option is not available to .NET code because

• we don't want to compile and distribute the custom OpenSSL bits as part of .NET Runtime
• shipping cryptography is problematic (I understand that some users may require that the implementation is somehow certified) and requires lots of resources/expertise to make the implementations secure.

OpenSSL seems to have gone in the direction of implementing QUIC on their own (currently work in progress IIRC). This suggests that it is unlikely that the changes made in the fork would be merged into the mainline OpenSSL to enable others to implement QUIC on top of OpenSSL.

TLS problems aside, the other problem is the manpower needed to make the implementation performant and bug-free. MsQuic has been in development for several years and there were multiple people working on it full-time, and those people have years of experience in low-level networking (low-level here means OS-level TCP stack development).

For these reasons, we are currently not considering moving to Managed QUIC in the near future.

However. If there are (or there will become) QUIC APIs available on Android, It would be a lot easier to have a different implementation for QuicConnection and other classes which would be used on Android. We already have different implementations of other parts of the runtime for some platforms (browser platform needs special handling in many networking cases).

[wfurt]

Agree with the original statement that dependencies are pain. But did you manage to get it working @John0King? AFAIK it should be possible to compile msquic for Android. We do not have tests but perhaps that is something we may improve e.g. increase test coverage even to platforms that are not fully supported. (like we do now for macOS)

microsoft/msquic#952 was closed but time moved on and perhaps it would be reasonable to ask MsQuic once again for binary packages. As @rzikm mentioned above the managed implementation was discussed but because of many technical challenges I don't see it coming anytime soon.

[ManickaP]

Triage: I'll keep this open for the sake of the discussion and discoverability. @rzikm comment summarized well why we chose not to pursue managed QUIC at the moment. But if anything from those reasons changes, we're always open to reevaluate the decision.

Also, if anyone tries to compile and use .NET with MsQuic on any platform outside of our official support and hits any issues. Please feel free to file a bug, we'll try to help make it work!