feat(protocol): negotiate registered gateway profiles

2026-07-30 04:47:52 +07:00
parent d26f8b60f8
commit e58f1c7c48
17 changed files with 227 additions and 67 deletions
@@ -19,7 +19,9 @@ The Data Plane already collects process-wide atomic counters and gauges. Only ac
 ## Decisions

 - Nest the values in required `GatewayTelemetry` so heartbeat telemetry is one strict atomic contract.
- Use cumulative counters and microsecond delay totals plus processing samples; consumers can derive rates/averages without losing raw observations.
+- Use cumulative counters and microsecond delay totals plus one processing sample per complete provider media unit; consumers can derive rates/averages without losing raw observations.
+- Define queue delay as residence in the bounded provider queue, processing as active recovery/framing/QUIC work excluding queue and scheduler waits, and pacing as scheduler wait only.
+- Derive measured egress from transmitted-byte deltas over monotonic elapsed time; configured capacity remains registration data.
 - Keep loss as parts per million and provider state as a bounded enum.

 ## Risks / Trade-offs
@@ -13,3 +13,10 @@ Heartbeat telemetry MUST reject unknown fields and MUST NOT include session, rou
 #### Scenario: Secret or high-cardinality field is attempted
 - **WHEN** a heartbeat contains an unregistered session, route, endpoint, credential, or payload field
 - **THEN** strict contract validation rejects it before authenticated transport
+
+### Requirement: Delay and egress observations have one canonical meaning
+Queue delay SHALL measure provider-queue residence, processing delay SHALL measure active gateway recovery/framing/QUIC work excluding queue and pacing, and pacing delay SHALL measure scheduler waiting only. Processing samples SHALL count complete provider media units rather than Verse fragments. Measured egress SHALL derive from transmitted-byte deltas over monotonic elapsed time and MUST NOT be copied from configured capacity.
+
+#### Scenario: One provider unit becomes multiple Verse frames
+- **WHEN** one complete provider unit waits in the queue, traverses gateway processing, waits for pacing, and fragments into multiple Verse frames
+- **THEN** each delay total includes only its defined interval and the heartbeat advances processing samples exactly once
@@ -3,6 +3,7 @@
 - [x] 1.1 Add bounded GatewayTelemetry to every heartbeat
 - [x] 1.2 Add Go, Rust, and Swift strict conformance checks
 - [x] 1.3 Regenerate bindings and prove deterministic output
+- [x] 1.4 Specify queue, processing, pacing, sample, and measured-egress semantics

 ## 2. Consumer Boundary

@@ -7,13 +7,15 @@ The Server resolves an immutable stream-policy version, but RC6 provider work ca
 **Goals:**

 - Carry only the effective launch settings required by the provider boundary.
+- Express client decode support as an ordered set of existing registered profiles.
+- Generate the same ordered registered-profile intersection for every consumer.
 - Generate identical validation from the canonical schema for all bindings.
 - Preserve the policy-version identifier for audit correlation.

 **Non-Goals:**

 - Publish or mutate RC6.
- Add provider-specific capability negotiation to Protocol.
+- Add a provider-specific token grammar or generic capability framework.
 - Expose provider work or policy internals to Verse clients.

 ## Decisions
@@ -22,11 +24,14 @@ The Server resolves an immutable stream-policy version, but RC6 provider work ca
 - Carry the Server-selected target bitrate rather than all policy bounds because Apollo ANNOUNCE consumes one configured bitrate.
 - Permit canonical `H264`, `HEVC`, and `AV1` values in the contract. A provider implementation must reject values it cannot honor rather than silently downgrade them.
 - Carry `audio_enabled` even though the current Apollo path cannot truthfully disable audio; the Data Plane must fail closed for that combination.
+- Change `client_decode` from one opaque string to a non-empty ordered unique array of registered profile identifiers. Preference belongs to the first peer's order.
+- Generate `IntersectCapabilityProfiles` from the canonical schema so Protocol, Server, and Data Plane do not maintain separate interpretations.

 ## Risks / Trade-offs

 - [New required field breaks RC6 consumers] → Publish only under a separately authorized new immutable version and pin both consumers after empty-cache resolution.
 - [Provider capabilities differ] → Validate the effective policy against the selected provider before readiness.
+- [Peers advertise no common registered profile] → Reject admission instead of inventing a combined token or silently downgrading.

 ## Migration Plan

@@ -5,6 +5,7 @@ Provider work identifies an immutable stream-policy version but omits the effect
 ## What Changes

 - Add the effective resolution, frame rate, codec, selected bitrate, and audio policy to authenticated provider work.
+- Represent decode support as an ordered set of registered profiles and generate one canonical intersection operation for consumers.
 - Require generated Go, Rust, and Swift bindings to validate the same bounded stream-policy contract.
 - Keep the new contract unpublished until a new immutable Protocol version is separately authorized.

@@ -12,7 +13,7 @@ Provider work identifies an immutable stream-policy version but omits the effect

 ### New Capabilities

- `provider-stream-policy`: Authenticated provider work carries the exact effective stream policy consumed by the provider launch.
+- `provider-stream-policy`: Authenticated provider work carries the exact effective stream policy consumed by the provider launch, and registered peers negotiate that policy through the shared ordered profile intersection.

 ### Modified Capabilities

@@ -13,3 +13,21 @@ Generated Go, Rust, and Swift bindings MUST reject missing, unknown, out-of-rang
 #### Scenario: Invalid policy is rejected consistently
 - **WHEN** provider work contains an unknown codec or a value outside the canonical bounds
 - **THEN** every generated binding rejects the work before it can reach provider setup
+
+### Requirement: Decode capabilities use registered ordered profiles
+`CapabilityProfile.client_decode` SHALL be a non-empty ordered unique set containing only registered `h264-opus` and `hevc-opus` profile identifiers. It MUST NOT encode multiple capabilities in an opaque private token.
+
+#### Scenario: Independent peer advertises one registered profile
+- **WHEN** an independent peer advertises one registered decode profile
+- **THEN** canonical validation accepts that profile without requiring a combined private token
+
+### Requirement: Consumers share one ordered registered-profile intersection
+Generated Protocol behavior SHALL select common registered profiles in the first peer's preference order. Provider consumers SHALL separately reject the resulting intersection when it cannot honor the immutable stream policy.
+
+#### Scenario: Policy-compatible profile overlaps
+- **WHEN** the gateway advertises HEVC then H.264 and the client advertises only H.264
+- **THEN** the shared intersection selects `h264-opus`
+
+#### Scenario: No policy-compatible profile overlaps
+- **WHEN** peers have no registered common profile
+- **THEN** the shared intersection rejects admission without inventing a private combined token
@@ -3,6 +3,8 @@
 - [x] 1.1 Add bounded effective stream policy to ProviderSessionWork
 - [x] 1.2 Add Go, Rust, and Swift conformance coverage
 - [x] 1.3 Regenerate bindings and prove deterministic output
+- [x] 1.4 Replace the opaque decode token with an ordered unique set of registered profiles
+- [x] 1.5 Generate and cross-check canonical ordered registered-profile intersection behavior

 ## 2. Consumer Boundary