Clarification on idle and idleConnection

[rahtr]

What question do you have?:
I am trying to find a clear distinction between the idle and idleConnection configuration? Based on the details in this doc-->
https://projectcontour.io/docs/main/config/api/#projectcontour.io/v1.TimeoutPolicy, it seems the

proxy:
  idle: 30s
  idleConnection: 1h

Explanation:
idle: 30s:
This setting means that if a connection between the proxy and the client is idle for 30 seconds during a single request/response cycle, the proxy will consider it idle. For HTTP/1.1, this applies to the time between requests on the same connection. For HTTP/2, it applies to the inactivity of streams.

Example:

• A client sends a request to the proxy.
• After the response is sent, if the client does not send another request within 30 seconds, the proxy will close the connection (assuming the connection remains idle).

idleConnection: 1h:
This setting means that if the connection between the proxy and the upstream service remains idle (no requests) for 1 hour, the proxy will close it.

Example:

• The proxy maintains a connection to the upstream service.
• If there are no active requests being sent through this connection for 1 hour, the proxy will close the connection to free up resources.

Combined Behavior:
During a request/response cycle:
If the idle timeout is reached (30 seconds without new requests on HTTP/1.1 or inactivity in HTTP/2 streams), the connection is considered idle, and the proxy might close it.

Between requests:
The idleConnection timeout (1 hour) ensures that even if the proxy is idle between requests, it won’t close the connection to the upstream service until 1 hour of inactivity has passed.

If the above understanding is correct then for this configuration:

proxy:
  idle: 300s
  idleConnection: 200s

If the connection to the upstream service is closed due to the idleConnection timeout, and the client then tries to send a request, it would indeed result in a failure if the proxy cannot establish a new connection to the upstream service in time.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• Contour version:
• Kubernetes version: (use kubectl version): v1.28.11
• Kubernetes installer & version:
• Cloud provider or hardware configuration: EKS
• OS (e.g. from /etc/os-release):

[github-actions]

Hey @rahtr! Thanks for opening your first issue. We appreciate your contribution and welcome you to our community! We are glad to have you here and to have your input on Contour. You can also join us on our mailing list and in our channel in the Kubernetes Slack Workspace

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[tsaarni]

idle: 300s
idleConnection: 200s

If the connection to the upstream service is closed due to the idleConnection timeout, and the client then tries to send a request, it would indeed result in a failure if the proxy cannot establish a new connection to the upstream service in time.

It seems that Envoy's How do I configure timeouts documentation doesn't cover this scenario. The idle setting manages Envoy's RouteAction.idle_timeout (Route timeout), and idleConnectioncontrols HttpProtocolOptions.idle_timeout (Connection timeout). I haven't tested this personally, I can't confirm whether this behavior occurs.

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack