Project: Kuma (Orchestration & Management / Service Mesh)
File: timeouts.md

Envoy allows users to configure plenty of different timeouts. All of them are applied to the different parts of configuration, all of them protects different stages of Connect / Request / Response process. There are the most important timeouts that Envoy allows to configure: - specifies the amount of time Envoy will wait for an upstream TCP connection to be established. Place: cluster Required: true Default: no Protocol: TCP - is defined as the period in which there are no bytes sent or received on either the upstream or downstream connection. Place: TCPProxy Required: false (0 value for disabling) Default: 1h Protocol: TCP - the idle timeout is the time at which a downstream or upstream connection will be terminated if there are no active streams. Place: HttpConnectionManager, Cluster Required: false Default: 1h Protocol: HTTP - the amount of time that Envoy will wait for the entire request to be received. The timer is activated when the request is initiated, and is disarmed when the last byte of the request is sent upstream (i.e. all decoding filters have processed the request), OR when the response is initiated. If not specified or set to 0, this timeout is disabled. This timeout is not compatible with streaming requests. Place: HttpConnectionManager Required: false (0 value for disabling) Default: not specified Protocol: HTTP - Total duration to keep alive an HTTP request/response stream. If the time limit is reached the stream will be reset independent of any other timeouts. Place: HttpConnectionManager, Cluster Required: false Default: not specified Protocol: HTTP - when an initiated request is being sent too slowly in a way that even the headers are not delivered at required intervals, Envoy will respond with a 408 error code. Place: HttpConnectionManager Required: false (0 value for disabling) Default: 5 min Protocol: HTTP - this spans between the point at which the entire downstream request (i.e. end-of-stream) has been processed and when the upstream response has been completely processed. Place: Route Required: false (0 value for disabling) Default: 15s Protocol: HTTP - the way to override [6] Place: Route Required: false (0 value for disabling) Default: not specified Protocol: HTTP - can be configured when using retries so that individual tries using a shorter timeout than the overall request timeout described above. This timeout only applies before any part of the response is sent to the downstream, which normally happens after the upstream has sent response headers. This timeout can be used with streaming endpoints to retry if the upstream fails to begin a response within the timeout. Place: Route Required: false Default: not specified Protocol: HTTP - the way to override [5] Place: Route Required: false (0 value for disabling) Default: not specified Protocol: HTTP - The amount of time that Envoy will wait for the request headers to be received. The timer is activated when the first byte of the headers is received, and is disarmed when the last byte of the headers has been

Place: HttpConnectionManager Required: false (0 value for disabling) Default: not specified Protocol: HTTP - If present and nonzero, the amount of time to allow incoming connections to complete any transport socket negotiations. If this expires before the transport reports connection establishment, the connection is summarily closed. Place: FilterChain Required: false Default: not specified Protocol: TCP As a service owner I want to propagate default recommended timeouts for applications which consumes my service so that they know approximately how much time it will take to request my service As a service owner I want to set service side timeouts so that I can protect my service from abusive application which is trying to consume it As a service consumer I want to set different timeouts for different outbounds of my application so that I can granularly make decisions regarding the time to wait for specific service As a service consumer I want to be able to overrider existing default recommended timeouts for the service that I consume so that I can control outgoing timeouts myself In order to satisfy all the use cases we can introduce 2 new policies: `Timeout` and `InboundTimeout`. Service A -> SRC Envoy -> -> -> DST Envoy -> Service B Timeout policy is a connection policy so it will be applied to the pair of service (A and B in the example). The idea of the policy is to instruct Service A how to request Service B. Example: ```yaml type: Timeout mesh: default name: default-timeouts-srv-B sources: match: kuma.io/service: '*' destinations: match: kuma.io/service: 'srv-B' conf: connectTimeout: 10s tcp: idleTimeout: 1h http: requestTimeout: 5s idleTimeout: 1h grpc: streamIdleTimeout: 5m maxStreamDuration: 30m ``` As an owner of Service B you have some SLA regarding the upper boundaries of the request/response time, so you can apply this `default-timeouts-srv-B` and every service which is trying to consume Service B will have those timeouts by default. At the same time if you are an owner of Service A you can override this policy for your service and put different timeout values. From the Service B perspective `default-timeouts-srv-B` policy has an advisory nature, every service can override it, `Timeout` policy is not purposed to protect Service B. In order to protect Service B from abusive clients with long requests its better to use `InboundTimeouts`. Unlike the `Timeout` this policy is matched for the Dataplane rather than pair of services (applied only to the Dataplanes of the Service B). `InboundTimeout` has the same configuration, but values are mapped to the different Envoy timeouts: ```yaml type: InboundTimeout mesh: default name: timeouts-srv-B selectors: match: kuma.io/service: srv-B conf: connectTimeout: 10s # 'transportsocketconnect_timeout' on FilterChain [12] tcp: idleTimeout: 1h http: requestTimeout: 10s requestHeadersTimeout: 5s idleTimeout: 1h grpc: streamIdleTimeout: 5s maxStreamDuration: 30m ``` This policy aims to protect your service from the long living requests, if the service is not designed to support them. There are 3 uncovered timeouts - [8], [9], [10]. [8] and [10] allows to override existing timeouts on per-route basis, probably it makes sense to implement them in L7 TrafficRoutes. [9] - probably makes sense to implement in the scope of Retry policy.