[HTTP/3] Developers can build libraries for HTTP/3 to meet their client/server needs

[samsp-msft]

HTTP3 is the next major version of HTTP and the successor to HTTP2. It is in the final stages of standardization in the IETF. Some browsers (notably Chrome) already support draft versions of HTTP3. HTTP3 runs over QUIC, which replaces TCP as the underlying transport. QUIC is also in the final stages of standardization in the IETF. It provides secure, multiplexed streams over UDP. QUIC is a general-purpose, extensible transport protocol and we expect it to be used by other application protocols aside from HTTP3.

Work Items

• A set of public classes for using the QUIC protocol on either client or server. This is System.Net.Quic. It is the equivalent of System.Net.Sockets for the QUIC protocol.
• HTTP3 client support in HttpClient/SocketsHttpHandler.
• Linux support
• MacOS support

P0

• [QUIC] QuicListener.ListenEndPoint returns a port of 0 if Start() hasn't been called #2262 - Improve QuicListener API to not have non-functional properties
• [QUIC] Update MsQuic GCHandles #31695 - Use GCHandles
• [QUIC] QuicStream.ReadAsync against an aborted connection returns End Of Stream #32050 - Fix stream read returning 0 on connection abort
• [QUIC] Implement better QUIC status code messages #32066 - Improve error messages and move to resources
• [QUIC] Use server TLS options in QUIC #32071 - TLS server options
• [QUIC] Improve error handling for QUIC event callbacks #32072 - Handle exceptions within MsQuic callbacks
• [QUIC] Don't leak QUIC session upon QuicListener disposal #32073 - Fix QuicListener disposal leaking MsQuic handles
• [QUIC] Finalize QUIC stream abort model #32075 - Finalize "abortive dispose" model
• [QUIC] Decide how to handle QUIC stream limits #32079 - Implement stream availability events
• [QUIC] Finalize QUIC dispose model #32142 - Finalize dispose model
• Update MsQuic #44580 - Update MsQuic
• [QUIC] Design of Shutdown for QuicStreams in System.Net.Quic #756 - Finalize shutdown behavior
• Add tests
• [QUIC] Use client TLS options in QUIC #32069 - TLS client options
• [QUIC] Support cancellation of QUIC writes #32077 - Implement Write cancellation support
• QuicConnection.RemoteEndPoint should be IPEndPoint, not EndPoint #43000 - Make RemoteEndPoint an IPEndPoint

P1

• [QUIC] Improve MSQuic OS Version detection #32575 - Implement platform compatibility detection
• [QUIC] Optimize stream reads #42651 - Optimized stream reads
• [QUIC] Use shared SocketAddress code in QUIC #32068 - Remove duplicate SOCKADDR code
• [QUIC] Support synchronous QUIC APIs #32076 - Optimize synchronous QuicStream APIs
• [QUIC] Does QUIC need sync versions of non-Stream APIs? #43792 - (Decide if needed and) Implement sync APIs
• [QUIC] Split out MsQuic configuration from connection #42642 - (Decide if needed and) Split out configuration APIs
• QuicStream: Consider requiring Flush to guarantee data is sent #44782 - Implement flush capability

P2

• [QUIC] Participate in QUIC interop testing #43061 - (Decide if needed and) Participate in QUIC interop testing

We have already made some progress on this in .NET 5.0 and are delivering HTTP3 support in a “preview”, unsupported capacity. There is no public API for QUIC in .NET 5.0.

We intend to share as much HTTP3 code as is reasonably possible between the client and server implementation.

[danmoseley]

@scalablecory @geoffkizer @karelz as a P0 story, we need to get a t-shirt cost for this by 11/13.

I am assuming that includes the first two of the list above.

@Pilchie who will cost the third one -- the work on the Kestrel side?

[Pilchie]

I expect @jkotalik is the best person on our side.

[jkotalik]

I marked this as XL (it's XL even for just the Kestrel work).

[danmoseley]

Is there some reasonable way to break this into child items, @jkotalik ? (For example, one item per entry in the list above, or more)

[jkotalik]

We are tracking this in the aspnetcore repo as well: dotnet/aspnetcore#15271. I'd put it on the runtime folks to determine if/how the want to split it up.

[jkotalik]

I'd cost adding HTTP/3 to Kestrel at ~20 weeks for everything (including perf/stress tests, implementation, abstractions, etc.)

[danmoseley]

Alright, I parented that under this. It's labeled Epic, but fine.

[scalablecory]

I think 12 weeks is enough for QUIC (MsQuic implementation) and client-side H3. @geoffkizer how do you feel about that?

[geoffkizer]

That seems a bit short to me.

I also think we should break out the MsQuic work vs the H3 work.

[danmoseley]

@scalablecory (or @geoffkizer ) could you please open (or link) appropriate user stori(es) for our work, similar to how the Kestrel one is linked above? Just tag with "User Story". Then we have a place for our own cost.

[samsp-msft]

@geoffkizer - Can we flush this out to sub issues?

[ghost]

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

Issue Details

---

HTTP3 is the next major version of HTTP and the successor to HTTP2. It is in the final stages of standardization in the IETF. Some browsers (notably Chrome) already support draft versions of HTTP3. HTTP3 runs over QUIC, which replaces TCP as the underlying transport. QUIC is also in the final stages of standardization in the IETF. It provides secure, multiplexed streams over UDP. QUIC is a general-purpose, extensible transport protocol and we expect it to be used by other application protocols aside from HTTP3.

Work Items

• A set of public classes for using the QUIC protocol on either client or server. This is System.Net.Quic. It is the equivalent of System.Net.Sockets for the QUIC protocol.
• HTTP3 client support in HttpClient/SocketsHttpHandler.

We have already made some progress on this in .NET 5.0 and are delivering HTTP3 support in a “preview”, unsupported capacity. There is no public API for QUIC in .NET 5.0.

We intend to share as much HTTP3 code as is reasonably possible between the client and server implementation.

Author:	samsp-msft
Assignees:	geoffkizer, samsp-msft
Labels:	Cost:XL, Priority:0, Team:Libraries, User Story, area-System.Net.Http
Milestone:	-

[karelz]

6.0 work has been finished -- all features we wanted are in. HTTP/3 is opt-in Preview feature in 6.0.

We will keep working on HTTP/3 and QUIC (incl. public APIs) during .NET 7.0 timeframe. This is being tracked with #57600, #57601.
Closing.