Is your feature request related to a problem?

None of the built-in policies route by observed latency. A backend that is slow but not failing
(GC pauses, a noisy neighbour, CPU throttling, a cold cache) keeps a full share of traffic, and
tail latency goes up for every caller:

• round_robin and pick_first ignore backend performance.
• least_request_experimental balances outstanding requests only, so it can't tell a slow backend
  from a busy one.
• weighted_round_robin needs servers to report ORCA load, which many deployments don't.
• outlier_detection reacts to failures, not slowness.

Describe the solution you'd like

A peak_ewma_experimental policy, using the algorithm from Finagle and Linkerd/tower that Envoy
now ships as a contrib load balancer
(envoy.extensions.load_balancing_policies.peak_ewma.v3alpha.PeakEwma):

• Per endpoint, keep a "peak" EWMA of client-observed RTT. It jumps up immediately on a slow
  response and decays over a configurable time, including while the endpoint isn't being picked,
  so it gets probed again and can recover.
• cost = peak_rtt × (outstanding_requests + 1)
• Per pick, sample choiceCount (default 2) READY endpoints and take the cheapest.

It would be structured like least_request (endpoint-level pick_first children, A61), with no
ejection of its own; users who want ejection wrap it in outlier_detection. Config is three
fields: choiceCount, decayTime, defaultRtt. It needs nothing from the server.

I'd write the gRFC and the Java implementation, following the A48 (least_request) precedent.

Describe alternatives you've considered

• least_request + outlier_detection: good for failures, but a uniformly slower backend
  isn't failing, so it keeps a large share (numbers below).
• weighted_round_robin with ORCA: more accurate where it's available, but it needs server
  cooperation. It doesn't help with third-party or legacy servers.
• Keeping it as an external library: this is what I do today
  (https://github.com/ParkerHarrelson/grpc-peak-ewma-lb). It works, but latency-aware balancing is
  a common need, and a built-in policy would be usable from service config and xDS without an
  extra dependency.
• Extending least_request with a latency mode: possible, but the cost function differs, and a
  separate policy maps cleanly onto Envoy's separate extension.

Additional context

I load-tested my standalone implementation against round_robin and
outlier_detection_experimental(least_request_experimental): 20 backends, one JVM per pod, real
gRPC over TCP, on a single machine (not yet a real cluster):

Client CPU per RPC was within noise of round_robin at 10 and 50 backends. The tested
implementation is a superset of what's proposed here (it adds per-method scoring and adaptive
decay); I'd re-run the tests with the minimal policy for the gRFC.

Before I write the gRFC:

1. Would the team consider this as an all-languages gRFC?
2. Should it map to Envoy's peak_ewma proto via A52, even though that proto is contrib/v3alpha?
   Or should it start as service-config only?
3. Is it acceptable to count only unary RPCs as RTT samples and outstanding load? A long-lived
   stream's duration isn't a latency. My concern is that other languages may not expose the method
   type at pick time.