At Lyft we have a desire to build a slow network simulation system. This would allow debug versions of our applications to request various slow network profiles, without requiring attachment to a special access point, emulator, etc.

Our plan is to do this via a new HTTP filter that has roughly the following capabilities:

1. Allow latency injection in both the downstream and upstream direction.
2. Allow throughput limiting in both the downstream and upstream direction.
3. Allow variable throughput/latency stability via randomness (to simulate spotty networks).

We would like to allow this via fixed configuration / xDS, but also, optionally, via request headers along the lines of:

x-envoy-throttle-response-throughput: int (kilobytes)
x-envoy-throttle-request-throughput: int (kilobytes)
x-envoy-throttle-response-throughput-stability: int (percentage between 0 and 100)
x-envoy-throttle-request-throughput-stability: int (percentage between 0 and 100)
x-envoy-throttle-response-latency: int (milliseconds)
x-envoy-throttle-request-latency: int (milliseconds)
x-envoy-throttle-network-stability: int (percentage between 0 and 100)

Potentially we would also offer pre-canned profiles, configurable via both static config and request headers such as:

x-envoy-throttle-profile: {“no-connection”, “EDGE”, “3G”, “LTE”}

In general, this code will not be difficult to write. There are some additional safety knobs we will need around max concurrent throttled requests, runtime disable, etc.

One thing to consider is whether this should be a new filter, or if we should build this functionality into the existing HTTP fault filter. My inclination is to build a new filter, but there is enough overlap that it might make sense to build this into the existing HTTP fault filter so I'm curious to hear everyone's opinion.

@envoyproxy/maintainers @rshriram @lita @Reflejo @goaway