docs: update EPP header references to x-llm-d (llm-d#1590)

* docs: update EPP header references to x-llm-d

Update EPP-managed header documentation to use the canonical x-llm-d names introduced by llm-d-router#1161.

Signed-off-by: wenhug <50309350+wenhug@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* docs: clarify EPP header alias compatibility

Signed-off-by: wenhug <50309350+wenhug@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Signed-off-by: wenhug <50309350+wenhug@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: wenhug

docs/api-reference/epp-http-headers.md

@@ -8,18 +8,34 @@ These headers allow the EPP to identify the request's goals, group them for fair
 
 | Header | Description |
 | --- | --- |
-| `x-gateway-inference-objective` | Specifies the name of the `InferenceObjective` resource associated with the request. The EPP uses this to look up the corresponding objective resource in the **same namespace as the InferencePool** to apply the defined priority and performance goals. |
-| `x-gateway-inference-fairness-id` | Provides a unique identifier for grouping requests for fairness-based flow control. Requests with the same ID share capacity according to the fairness policy. If omitted, the EPP defaults to `default-flow`. |
-| `x-gateway-model-name-rewrite` | Specifies the target model name to be used for the request. This is an alternative approach to model name rewriting; while the `InferenceModelRewrite` API provides rule-based rewriting on the server side, this header allows for an explicit, per-request override. When present, the EPP uses this value to override the model name in the request body and for recording model-specific metrics. |
+| `x-llm-d-inference-objective` | Specifies the name of the `InferenceObjective` resource associated with the request. The EPP uses this to look up the corresponding objective resource in the **same namespace as the InferencePool** to apply the defined priority and performance goals. |
+| `x-llm-d-inference-fairness-id` | Provides a unique identifier for grouping requests for fairness-based flow control. Requests with the same ID share capacity according to the fairness policy. If omitted, the EPP defaults to `default-flow`. |
+| `x-llm-d-model-name-rewrite` | Specifies the target model name to be used for the request. This is an alternative approach to model name rewriting; while the `InferenceModelRewrite` API provides rule-based rewriting on the server side, this header allows for an explicit, per-request override. When present, the EPP uses this value to override the model name in the request body and for recording model-specific metrics. |
 
 ## Service Level Objectives (SLOs)
 
 These headers are used by admission control and load balancing plugins to make decisions based on latency targets.
 
 | Header | Description |
 | --- | --- |
-| `x-slo-ttft-ms` | Specifies the target Time To First Token (TTFT) in milliseconds. Used by plugins to determine if a request can be admitted while meeting the latency goal. |
-| `x-slo-tpot-ms` | Specifies the target Time Per Output Token (TPOT) in milliseconds. Used for admission control based on predicted or observed token generation latency. |
+| `x-llm-d-slo-ttft-ms` | Specifies the target Time To First Token (TTFT) in milliseconds. Used by plugins to determine if a request can be admitted while meeting the latency goal. |
+| `x-llm-d-slo-tpot-ms` | Specifies the target Time Per Output Token (TPOT) in milliseconds. Used for admission control based on predicted or observed token generation latency. |
+
+## Deprecated Aliases
+
+llm-d Router [v0.9.0](https://github.com/llm-d/llm-d-router/releases/tag/v0.9.0) and later accept the previous EPP-managed header names as deprecated read aliases. New integrations and examples should use the canonical `x-llm-d-*` names. Earlier releases expect the previous names, so mixed-version fleets should coordinate the header migration during rolling upgrades.
+
+If a request sends both a canonical header and its deprecated alias, the canonical `x-llm-d-*` value wins deterministically. No alias removal release or date has been announced; treat aliases as temporary compatibility support and prefer the canonical names for all new clients.
+
+| Deprecated alias | Canonical header |
+| --- | --- |
+| `x-gateway-inference-fairness-id` | `x-llm-d-inference-fairness-id` |
+| `x-gateway-inference-objective` | `x-llm-d-inference-objective` |
+| `x-gateway-model-name-rewrite` | `x-llm-d-model-name-rewrite` |
+| `x-slo-ttft-ms` | `x-llm-d-slo-ttft-ms` |
+| `x-slo-tpot-ms` | `x-llm-d-slo-tpot-ms` |
+
+This rename applies only to llm-d/EPP-managed user and control headers. [Gateway API Inference Extension (GAIE) Endpoint Picker Protocol](https://github.com/kubernetes-sigs/gateway-api-inference-extension/tree/main/docs/proposals/004-endpoint-picker-protocol) headers, such as `x-gateway-destination-endpoint*`, are unchanged.
 
 ## Response Headers
 

docs/architecture/advanced/latency-predictor.md

@@ -97,7 +97,7 @@ Each prediction sidecar sustains roughly 300 QPS of prediction work on a `c4-sta
 The `predicted-latency-producer` plugin has two training modes, exposed via a `streamingMode` parameter:
 
 - **`streamingMode: false`** (default) — Trains on end-to-end request latency. TTFT is recorded at response completion (effectively e2e latency); TPOT is not trained. **Use this mode if** your workload mixes streaming and non-streaming responses, or if you only need latency-aware routing without per-request SLO enforcement.
-- **`streamingMode: true`** — Trains separate TTFT and TPOT models. TTFT is recorded on the first streamed chunk; TPOT is sampled across subsequent tokens. **Use this mode if** your workload is fully streaming and you need meaningful `x-slo-ttft-ms` / `x-slo-tpot-ms` enforcement — a mixed workload in this mode will produce incorrect measurements for the non-streamed responses.
+- **`streamingMode: true`** — Trains separate TTFT and TPOT models. TTFT is recorded on the first streamed chunk; TPOT is sampled across subsequent tokens. **Use this mode if** your workload is fully streaming and you need meaningful `x-llm-d-slo-ttft-ms` / `x-llm-d-slo-tpot-ms` enforcement — a mixed workload in this mode will produce incorrect measurements for the non-streamed responses.
 
 ## Scheduling Strategy
 

docs/architecture/core/router/epp/flow-control.md

@@ -27,7 +27,7 @@ The Flow Control layer intercepts requests at the EPP and holds them in centrali
 To understand how policy plugins act, it helps to visualize the queuing topology as a grid defined by two dimensions: **Priority** and **Flow (Fairness ID)**.
 
 1. **Flow Identification**: Every request is assigned a `FlowKey` — a tuple of `(FairnessID, Priority)`.
-    * `FairnessID` is extracted from the `x-gateway-inference-fairness-id` header (e.g., tenant ID).
+    * `FairnessID` is extracted from the `x-llm-d-inference-fairness-id` header (e.g., tenant ID).
     * `Priority` is derived from the `InferenceObjective`.
 2. **Separate Queues**: Each unique `FlowKey` maps to its own in-memory queue.
 
@@ -48,8 +48,8 @@ Here is an example of how to target a specific `InferenceObjective` and ensure f
 ```bash
 curl -X POST http://${IP}:${PORT}/v1/completions \
   -H 'Content-Type: application/json' \
-  -H 'x-gateway-inference-fairness-id: tenant-a' \
-  -H 'x-gateway-inference-objective: premium-traffic' \
+  -H 'x-llm-d-inference-fairness-id: tenant-a' \
+  -H 'x-llm-d-inference-objective: premium-traffic' \
   -d '{
     "model": "default-model",
     "prompt": "Say hello"
@@ -362,7 +362,7 @@ The Flow Control layer behavior is customizable via several extension points imp
 
 * **[`fcfs-ordering-policy`](https://github.com/llm-d/llm-d-router/tree/main/pkg/epp/framework/plugins/flowcontrol/ordering/fcfs/README.md)**: First-Come, First-Served based on arrival time. (Default)
 * **[`edf-ordering-policy`](https://github.com/llm-d/llm-d-router/tree/main/pkg/epp/framework/plugins/flowcontrol/ordering/edf/README.md)**: Earliest Deadline First, prioritizing requests with the closest expiration time.
-* **[`slo-deadline-ordering-policy`](https://github.com/llm-d/llm-d-router/tree/main/pkg/epp/framework/plugins/flowcontrol/ordering/slodeadline/README.md)**: Orders requests by an SLO-based deadline computed from arrival time. Uses the `x-slo-ttft-ms` header. Requests without this header are placed behind all SLO requests, risking starvation.
+* **[`slo-deadline-ordering-policy`](https://github.com/llm-d/llm-d-router/tree/main/pkg/epp/framework/plugins/flowcontrol/ordering/slodeadline/README.md)**: Orders requests by an SLO-based deadline computed from arrival time. Uses the `x-llm-d-slo-ttft-ms` header. Requests without this header are placed behind all SLO requests, risking starvation.
 
 #### Saturation Detectors
 

docs/getting-started/README.md

@@ -61,7 +61,7 @@ Split inference into dedicated **prefill workers** (prompt processing) and **dec
 
 ### Predicted Latency-Based Routing
 
-An **llm-d Router** capability implemented primarily as an EPP plugin that routes each request to the replica predicted to serve it fastest, using an XGBoost model trained online on live traffic to predict ITL and TTFT. Optionally enforce per-request SLOs via `x-slo-ttft-ms` / `x-slo-tpot-ms` headers — requests that no replica can meet within budget are shed at admission rather than routed to a guaranteed miss. Useful when workload variance makes queue-depth a poor proxy for true load, or when clients need to express interactive vs. batch latency budgets.
+An **llm-d Router** capability implemented primarily as an EPP plugin that routes each request to the replica predicted to serve it fastest, using an XGBoost model trained online on live traffic to predict ITL and TTFT. Optionally enforce per-request SLOs via `x-llm-d-slo-ttft-ms` / `x-llm-d-slo-tpot-ms` headers — requests that no replica can meet within budget are shed at admission rather than routed to a guaranteed miss. Useful when workload variance makes queue-depth a poor proxy for true load, or when clients need to express interactive vs. batch latency budgets.
 
 ### Batch Inference
 

guides/flow-control/README.md

@@ -238,8 +238,8 @@ Clients must send the appropriate headers to be placed in the correct queues.
 ```bash
 curl -X POST http://${IP}/v1/completions \
   -H 'Content-Type: application/json' \
-  -H 'x-gateway-inference-fairness-id: tenant-a' \
-  -H 'x-gateway-inference-objective: premium-traffic' \
+  -H 'x-llm-d-inference-fairness-id: tenant-a' \
+  -H 'x-llm-d-inference-objective: premium-traffic' \
   -d "{
     \"model\": \"${MODEL_NAME}\",
     \"prompt\": \"Say hello\"
@@ -249,7 +249,7 @@ curl -X POST http://${IP}/v1/completions \
 > [!WARNING]
 > **Trust Boundary**: In a production system, allowing end-users to self-assert their tenant ID or traffic priority (`premium-traffic`) is an abuse vector.
 >
-> **Production Pattern**: Your ingress API Gateway (or an Envoy `ext_authz` filter) should be configured to automatically strip any incoming `x-gateway-*` headers from external traffic. It should then validate the user's API Key or JWT, extract their tier/tenant from the token claims, and securely inject the authoritative `x-gateway-inference-fairness-id` and `x-gateway-inference-objective` headers before passing the request to the EPP.
+> **Production Pattern**: Your ingress API Gateway (or an Envoy `ext_authz` filter) should be configured to automatically strip any incoming `x-llm-d-*` headers, plus the deprecated EPP-managed aliases listed in the [EPP HTTP headers reference](../../docs/api-reference/epp-http-headers.md), from external traffic. Gateway API Inference Extension (GAIE) endpoint picker protocol headers such as `x-gateway-destination-endpoint*` are not part of this stripping rule. After stripping, validate the user's API Key or JWT, extract their tier/tenant from the token claims, and securely inject the authoritative `x-llm-d-inference-fairness-id` and `x-llm-d-inference-objective` headers before passing the request to the EPP.
 
 ### Use Case 2: Backpressure Management
 
@@ -279,8 +279,8 @@ To verify backpressure management, you must overwhelm the pool's capacity. Becau
 
     ```bash
     hey -c 150 -n 150 -m POST -T "application/json" \
-      -H "x-gateway-inference-fairness-id: tenant-b" \
-      -H "x-gateway-inference-objective: best-effort-traffic" \
+      -H "x-llm-d-inference-fairness-id: tenant-b" \
+      -H "x-llm-d-inference-objective: best-effort-traffic" \
       -D payload.json http://${IP}/v1/completions
     ```
 

guides/predicted-latency-routing/README.md

@@ -62,7 +62,7 @@ Two ready-to-use values files ship with this guide:
 | File | When to use |
 |---|---|
 | [`router/predicted-latency.values.yaml`](./router/predicted-latency.values.yaml) | Default — predictor trains on end-to-end latency. Routing-only, no SLO header support. |
-| [`router/predicted-latency-slo.values.yaml`](./router/predicted-latency-slo.values.yaml) | SLO-aware — Assumes `x-slo-ttft-ms` / `x-slo-tpot-ms` are set on requests. Every request must be sent with `"stream": true`. |
+| [`router/predicted-latency-slo.values.yaml`](./router/predicted-latency-slo.values.yaml) | SLO-aware — Assumes `x-llm-d-slo-ttft-ms` / `x-llm-d-slo-tpot-ms` are set on requests. Every request must be sent with `"stream": true`. |
 
 Both target model server pods labeled `llm-d.ai/guide=optimized-baseline` since in the next step we will simply reuse the model server manifests from the [optimized-baseline guide](../optimized-baseline).
 
@@ -126,8 +126,8 @@ Once enabled, latency-based scheduling works on every request — no header chan
 
 To opt an individual request into SLO-aware routing, add one or both headers:
 
-- `x-slo-ttft-ms` — Time-to-first-token SLO in milliseconds.
-- `x-slo-tpot-ms` — Time-per-output-token SLO in milliseconds.
+- `x-llm-d-slo-ttft-ms` — Time-to-first-token SLO in milliseconds.
+- `x-llm-d-slo-tpot-ms` — Time-per-output-token SLO in milliseconds.
 
 ### 1. Get the IP of the Proxy
 
@@ -164,8 +164,8 @@ kubectl run curl-debug --rm -it \
 ```bash
 curl -X POST http://${IP}/v1/completions \
     -H 'Content-Type: application/json' \
-    -H 'x-slo-ttft-ms: 200' \
-    -H 'x-slo-tpot-ms: 50' \
+    -H 'x-llm-d-slo-ttft-ms: 200' \
+    -H 'x-llm-d-slo-tpot-ms: 50' \
     -d '{
         "model": "'${MODEL_NAME}'",
         "prompt": "Explain the difference between prefill and decode.",

guides/predicted-latency-routing/router/predicted-latency-slo.values.yaml

@@ -1,7 +1,7 @@
 ## Predicted Latency-Based Scheduling — SLO-aware setup (streamingMode: true).
 ##
 ## Overrides the chart's default plugin pipeline so predicted-latency-producer
-## trains on streaming TPOT samples. Required for x-slo-ttft-ms / x-slo-tpot-ms
+## trains on streaming TPOT samples. Required for x-llm-d-slo-ttft-ms / x-llm-d-slo-tpot-ms
 ## request headers to be honored. Every request must be sent with
 ## "stream": true in the body.
 ##

guides/predicted-latency-routing/router/predicted-latency.values.yaml

@@ -1,7 +1,7 @@
 ## Predicted Latency-Based Scheduling — default (routing-only) setup.
 ##
 ## The predictor trains on end-to-end latency. Suitable for non-SLO traffic.
-## For SLO header support (x-slo-ttft-ms / x-slo-tpot-ms), use
+## For SLO header support (x-llm-d-slo-ttft-ms / x-llm-d-slo-tpot-ms), use
 ## predicted-latency-slo.values.yaml instead.
 
 router: