In 2.1, we provided a "tech preview" rate limiting implementation to make up for the loss of rate limiting as an Istio feature with Mixer's removal (in Istio 1.8). 

Since Mixer was removed as a consolidation point in Istio's architecture, rate limiting has become a "bolt on" feature for Istio. It requires an external rate-limiting server application to be deployed to manage rate limiting data across multiple application pods. This rate limiting server also requires storage to manage this data. Upstream documents how to implement rate limiting using a non-production grade demo server. A production version would require a Redis server for managing rate limiting data.

The tech preview solution provided in 2.1 (https://issues.redhat.com/browse/MAISTRA-2395), configures a similar solution via SMCP, though the rate limit server created is not production grade. We also are not able to support Redis if needed for production.

This epic is to create a supported rate limiting implementation for OpenShift Service Mesh, with a GA supported API and likely a GA supported rate limit server application. We will not be supporting Redis, though we should consider if there are any OpenShift supported storage solutions (or partner solutions) that could be recommended in its place. A clear support boundary should be established between OSSM and any storage implementation.

We should also look to align with 3Scale's rate limiting implementation, which will also be Envoy based. Aligning APIs and avoiding duplication of efforts with 3Scale is important.