Change SocketsHttpHandler's default ConnectTimeout to a reasonable finite value

[CarnaViire]

Windows will timeout a connection attempt after ~21s. Linux apparently waits much longer – around 3 minutes or more.

The connection pooling changes in 6.0 made it so that a pending connection is not associated with a specific request. As such, request cancellation no longer causes pending connections to be canceled. We do not impose any connect timeout by default (DefaultConnectTimeout = Timeout.InfiniteTimeSpan), so we are now exposed to Linux’s long connection timeout. In case of small request timeouts, this may lead to a potentially big number of requests timing out as they try to wait/reuse the same "pending" connection.

We should set a default ConnectTimeout to something reasonably small. We should also consider backporting that to 6.0.

I propose to unify Windows and Linux timeouts, i.e. set DefaultConnectTimeout to 21s.

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

Issue Details

---

Windows will timeout a connection attempt after ~21s. Linux apparently waits much longer – around 3 minutes or more.

The connection pooling changes in 6.0 made it so that a pending connection is not associated with a specific request. As such, request cancellation no longer causes pending connections to be canceled. We do not impose any connect timeout by default (DefaultConnectTimeout = Timeout.InfiniteTimeSpan), so we are now exposed to Linux’s long connection timeout. In case of small request timeouts, this may lead to a potentially big number of requests timing out as they try to wait/reuse the same "pending" connection.

We should set a default ConnectTimeout to something reasonably small. We should also consider backporting that to 6.0.

I propose to unify Windows and Linux timeouts, i.e. set DefaultConnectTimeout to 21s.

Author:	CarnaViire
Assignees:	-
Labels:	area-System.Net.Http, untriaged
Milestone:	-

[stephentoub]

This seems reasonable. Technically it's a breaking change, but if a connection is taking that long to be established, it's likely going to fail, anyway. There's also value in consistency across platforms.

Is the exception that occurs in the case of a timeout due to ConnectTimeout the same that occurs in response to the OS timing out a connection?

[CarnaViire]

Is the exception that occurs in the case of a timeout due to ConnectTimeout the same that occurs in response to the OS timing out a connection?

Unfortunately, no.

If OS did the timeout, the error would bubble up from sockets, so we would see HttpRequestException with inner SocketException ((110): Connection timed out on Linux and (10060): A connection attempt failed because the connected party did not properly respond after a period of time.... on Windows)

If it was our timeout, we would see TaskCanceledException with inner TimeoutException: A connection could not be established within the configured ConnectTimeout.

[geoffkizer]

Perhaps we should use 15s. That means that typically we'd do the timeout ourselves on both platforms. It's also a reasonably round number as compared to 21s.

[MihaZupan]

Since we try connecting to all IPs returned by DNS (currently in serial), would changing the ConnectTimeout to something lower than the OS's timeout change the behavior so that we may no longer end up trying different IPs?

[CarnaViire]

Since we try connecting to all IPs returned by DNS (currently in serial), would changing the ConnectTimeout to something lower than the OS's timeout change the behavior so that we may no longer end up trying different IPs?

You are right 😢 and we currently don't have any per-IP timeout for multi-connect in Sockets (only a cancellation token for the whole operation) -- should we consider some new API like that?

[ManickaP]

would changing the ConnectTimeout to something lower than the OS's timeout change the behavior so that we may no longer end up trying different IPs?

Only in case of Windows. In case of Linux, we're not losing anything, since the OS timeout ends up being ~2 minutes. The user can always change it back to infinite if this proves problematic. They can also implement their own ConnectCallback.

Eventually we could do something like happy eyeballs and try to connect to multiple IPs in parallel (related #26177).

[wfurt]

Even with eyeballs, you can have multiple addresses for the same family. And only some of them may be unreachable/unresponsive. But I would feel in most cases callers would care about overall responsiveness instead of details for each individual address.

[ManickaP]

By "something like happy eyeballs" I meant trying the parallel connect, even to multiple addresses of the same family at the same time. This is just an idea so please do not crucify me on all the details and pitfalls. I'm aware this wouldn't be as easy as running n connects in n tasks and seeing which finishes first. It would need to be carefully designed to not to drag down perf, hog ephemeral ports etc.

[CarnaViire]

Linking the existing issue containing API for socket's happy-eyeball-like parallel connect #33418
We might want to revisit it and add more flexible options, e.g. not connecting to all IPs at once, but rather try to connect to the first IP, wait for 5s, and if it doesn't connect, try to connect to the second one without cancelling the first one, etc.

[CarnaViire]

Triage: change DefaultConnectTimeout to 15s in 7.0 (breaking change).
Multi-connect issues should be relatively rare. If it occurs, ConnectTimeout could be to set back to a big value. If we would see demand we would prioritize socket connect changes linked above.
For 6.0, consider adding telemetry to help troubleshoot hanged "pending" connection issue.