GEP: Timeouts

[youngnick]

What would you like to be added:

Gateway API needs whatever support we can do for timeouts. This GEP is to consider what timeouts are available, find some common ground, and then to implement that common ground somehow. (Very likely a Policy object, but not certain).

Why this is needed:
Timeouts are a critical part of any proxy infrastructure, and since many Gateway implementations use a proxy, they're important here as well.

[youngnick]

The first step here is a preliminary GEP PR that talks about the Why and What we need to do; in this case this includes a review of all the implementations, what dataplanes they use, and what information we have about the data plane's timeout capabilities. That should set us up for what we can do, which can then help us define what we will do.

I've already done the comparison, and am in the process of writing this PR up.

[shaneutt]

@arkodg provided several details relevant to this in #1741 which we should reference while working here.

[candita]

@youngnick
Would like to request discussion of:

• tunnel timeouts (for websocket connections, maybe the same use case as @liangyuanpeng mentioned above
• server-side connection timeouts

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[youngnick]

/remove-lifecycle stale

[rainest]

With https://gateway-api.sigs.k8s.io/geps/gep-1742/#timeout-values and #2013 there's no option that NGINX-based implementations would support, correct? I don't know of any that add timeout behaviors other than the idle/time between individual reads behavior offered by ngx_http_proxy_module (https://github.com/openresty/lua-resty-core/blob/master/lib/ngx/balancer.md#set_timeouts just configures those for the lua-nginx-module-based implementations).

Would a TTFB timeout or idle timeout make sense as an alternative? Idle appears to have the widest support, as it's available in Envoy (idle_timeout), NGINX (proxy_read_timeout), and HAProxy (timeout server). Traefik does have idleConnTimeout, but I don't read that as applying within a request, only after for open inactive connections similar to NGINX's keepalive_timeout.

Idle timeout de facto satisfies TTFB (inclusive of headers) insofar as a connection not receiving response headers is idle after the client headers and body are sent, albeit with caveats after that a pure idle timeout can time out after headers are received also. Traefik does support a headers-only timeout (forwardingTimeouts.responseHeaderTimeout) for that.

IDK how we'd eventually structure the config, but I'd also expect idle to be the main option for L4 routes, since we don't really have much universal there besides time between packets.

Lastly, despite the

A standard API for every possible timeout that implementations may support.

non-goal, I think it'd make sense to have an ImplementationSpecific option that lets you specify a Duration and string identifier. That's maybe less a standard API for each and more an acknowledgement that we know the timeout options across implementations are quite varied and that we'll probably never have standard APIs for all. However, reviewing the offerings does indicate that most could be handled with a basic duration+identifier combo--I don't see any that clearly use more complex configuration.

Although the extensionRef HTTPRouteFilter is available as an alternative at the HTTPRouteRule level, having timeouts split across two sections depending on whether they're standard or not feels bad at a UX level.

[tao12345666333]

According to GEP-713, perhaps we can try adding a TimeoutPolicy and redefining some specific behaviors?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[kflynn]

Not stale...

[kflynn]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[kflynn]

I think we’re going to make this a goal for v1.2…

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[kflynn]

Definitely not stale. 😂

/remove-lifecycle stale

[shaneutt]

/lifecycle frozen
/priority important-soon