QUIC: handling of timeouts should be improved

[wfurt]

Currently we set timeout in SafeMsQuicConfigurationHandle

runtime/src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/Interop/SafeMsQuicConfigurationHandle.cs

Lines 118 to 127 in 633e044

	if (options.IdleTimeout != Timeout.InfiniteTimeSpan)
	{
	if (options.IdleTimeout <= TimeSpan.Zero) throw new Exception("IdleTimeout must not be negative.");
	ulong ms = (ulong)options.IdleTimeout.Ticks / TimeSpan.TicksPerMillisecond;
	if (ms > (1ul << 62) - 1) throw new Exception("IdleTimeout is too large (max 2^62-1 milliseconds)");
	settings.IsSetFlags |= QuicSettingsIsSetFlags.IdleTimeoutMs;
	settings.IdleTimeoutMs = (ulong)options.IdleTimeout.TotalMilliseconds;
	}

When timeout is Timeout.InfiniteTimeSpan we should set the value to 0.
If we skip setting it, default 30s timeout would still apply.

There is separate timeout setting for Connect. So if somebody wishes to control that either by allowing more time on slow network or vice versa they currently cannot do that via timeouts. (smaller timeout can be enforced via cancellation token as mitigation ) We can either apply current timeout in both cases or split the timeout setting.

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

Issue Details

---

Currently we set timeout in SafeMsQuicConfigurationHandle

runtime/src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/Interop/SafeMsQuicConfigurationHandle.cs

Lines 118 to 127 in 633e044

	if (options.IdleTimeout != Timeout.InfiniteTimeSpan)
	{
	if (options.IdleTimeout <= TimeSpan.Zero) throw new Exception("IdleTimeout must not be negative.");
	ulong ms = (ulong)options.IdleTimeout.Ticks / TimeSpan.TicksPerMillisecond;
	if (ms > (1ul << 62) - 1) throw new Exception("IdleTimeout is too large (max 2^62-1 milliseconds)");
	settings.IsSetFlags |= QuicSettingsIsSetFlags.IdleTimeoutMs;
	settings.IdleTimeoutMs = (ulong)options.IdleTimeout.TotalMilliseconds;
	}

When timeout is Timeout.InfiniteTimeSpan we should set the value to 0.
If we skip setting it, default 30s timeout would still apply.

There is separate timeout setting for Connect. So if somebody wishes to control that either by allowing more time on slow network or vice versa they currently cannot do that via timeouts. (smaller timeout can be enforced via cancellation token as mitigation ) We can either apply current timeout in both cases or split the timeout setting.

Author:	wfurt
Assignees:	-
Labels:	area-System.Net.Quic
Milestone:	-

[GSPP]

Maybe the timeout should be rounded in order to improve precision?

[karelz]

Triage: We do not disable timeout on msquic when we get Timeout.InfiniteTimeSpan from API -- should be simple to rearrange.