QuicTransportOptions.IdleTimeout vs KestrelServerLimits.KeepAliveTimeout

[Tratcher]

These two settings appear to serve the same purpose at different layers. Consider how to remove QuicTransportOptions.IdleTimeout and get that value from KestrelServerLimits.KeepAliveTimeout during bind, probably as a feature.

aspnetcore/src/Servers/Kestrel/Transport.Quic/src/QuicTransportFactory.cs

Lines 49 to 63 in fce1e38

	public ValueTask<IMultiplexedConnectionListener> BindAsync(EndPoint endpoint, IFeatureCollection? features = null, CancellationToken cancellationToken = default)
	{
	var sslServerAuthenticationOptions = features?.Get<SslServerAuthenticationOptions>();
	if (sslServerAuthenticationOptions == null)
	{
	throw new InvalidOperationException("Couldn't find HTTPS configuration for QUIC transport.");
	}
	if (sslServerAuthenticationOptions.ServerCertificate == null)
	{
	var message = $"{nameof(SslServerAuthenticationOptions)}.{nameof(SslServerAuthenticationOptions.ServerCertificate)} must be configured with a value.";
	throw new InvalidOperationException(message);
	}
	var transport = new QuicConnectionListener(_options, _log, endpoint, sslServerAuthenticationOptions);

aspnetcore/src/Servers/Kestrel/Transport.Quic/src/Internal/QuicConnectionListener.cs

Line 48 in fce1e38

quicListenerOptions.IdleTimeout = options.IdleTimeout;

Problem: QuicTransportOptions.IdleTimeout causes connections to be dropped without sending the HTTP/3 GOAWAY. The GOAWAY is intended to mitigate race conditions when starting new streams. We also don't want the IdleTimeout to be different from KestrelServerLimits.KeepAliveTimeout.

Proposal:

• Remove QuicTransportOptions.IdleTimeout and disable the underlying QuicListenerOptions.IdleTimeout setting (MaxValue?). We're marking QuicTransportOptions as preview API so we can modify it without regards for back compat.
• Explicitly manage HTTP/3 connection lifetimes at the Kestrel layer using KeepAliveTimeout, the same way we do for to HTTP/1 and HTTP/2. Send GOAWAYs before closing connections.

Update:
Should maximum concurrent streams be exposed via Http3Limits and automatically set on QuicTransportOptions.MaxConcurrentStreams?

Thanks for contacting us.

We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Tratcher]

Per #32034, it might make sense to move all of QuicTransportOptions up to various Kestrel options.

[Tratcher]

@wtgodbe I'm going to re-use this issue for the .NET 7 work.

Problem: QuicTransportOptions.IdleTimeout causes connections to be dropped without sending the HTTP/3 GOAWAY. The GOAWAY is intended to mitigate race conditions when starting new streams. We also don't want the IdleTimeout to be different from KestrelServerLimits.KeepAliveTimeout.

Proposal:

• Remove QuicTransportOptions.IdleTimeout and disable the underlying QuicListenerOptions.IdleTimeout setting (MaxValue?). We're marking QuicTransportOptions as preview API so we can modify it without regards for back compat.
• Explicitly manage HTTP/3 connection lifetimes at the Kestrel layer using KeepAliveTimeout, the same way we do for to HTTP/1 and HTTP/2. Send GOAWAYs before closing connections.