When running Envoy on both egress and ingress, the client will provide a timeout header to the egress Envoy, which will propagate the expected upstream timeout in x-envoy-expected-rq-timeout-ms. The upstream Envoy will not read this header, so it will resolve a new timeout value that is set as the expected timeout for the upstream service. This means that the deadline expected by the egress Envoy is ignored in favor of the ingress Envoy, resulting in the upstream service having an incorrect view of the actual deadline.

It seems like either

1. inserting x-envoy-rq-timeout-ms with the expected timeout on egress
2. parsing x-envoy-expected-rq-timeout-ms as the deadline on the ingress side

would solve the issue (likely guarded by a config flag).

Thoughts?